A part of the story is that to get the ball rolling I want walkability extensions to be as cheap as possible to implement. So I want to give the implementations some choice in implementing the CDR; which means that environment handling support is not directly for users as much as for building a portable library on top of it. Agreeing on a single API is more risk and more negotiations than analyzing the existing APIs and defining various sufficient subsets that are already sufficient, as well as identifying the options for improvements when more is available. User APIs on top of that can evolve as Quicklisp-installable libraries before we need to agree on the precise best approach.
I think that there should be a single spec to avoid incompatible coverage. I agree that having it relatively low-level is fine. I think that a test suite covering various corner cases would be a very good initial step. We could include it in ansi-test library in ansi-beyond suite.
From the point of view of better chances of support from diverse implementations, I expect the suboptimal Javascript-style non-uniform support with easy feature-probing and «polyfill» libraries to be useful for solving chicken-and-egg problem: we need useful libraries to show something is worth implementing well, and we need working support to try writing the useful libraries.