My plan for walkability is: compliance with CDR-NN requires having a package with name CDR-NN that has all the symbols defined in CDR- NN.
IMHO if CDR's are truly meant as a process to augument standarization then all that should be in a single package (with an additional "CDR- USER" package which uses CL and CDR and is not locked). That will ensure that there are no symbol conflicts and it is indeed a possible candidate for inclusion a "base" package. Also too many packages is a tedious disease of many systems.
I agree with the goal of eventually having a usable CDR/CDR-USER package. I don't think this should be defined by the next coming CDR. Currently the CDR process is defined in a way that is best suited for defining small isolated things. I agree it would be useful to define a decision-making process that could be used for filling a single extension namespace in a consistent and widely respected way. I think defining such a process requires a discussion with buy-in from multiple implementations, and I hope to revive CDR as a recognised discussion place, but my plan starts with discussing something concrete — starting with a meta-discussion about rules has its own failure modes. So I am not ready to start defining a CDR package with the (coordination) tools I see, but I think there is hope to improve the situation. 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. 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.