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.
In other portability-sensitive areas, I think CFFI and Bordeaux- Threads will stay but it is good to have a defined foundation that a new implementation or a fork can provide and immediately get full support.
CFFI in ECL's case is baked by ECL's UFFI implementation (ECL implements UFFI protocol and said protocol is fairly simple). Daniel