Regarding the feedback, here are some notes I had when I've started writing a test suite before starting implementing cltl2 in ECL, maybe you'll find some of them useful. I plan to tackle this problem again after upcoming 16.2.0 release (with some refactor of the compiler interfces). I'll definetely look into the walkability document before doing so.
Hm, interesting. Indeed, I should include at least optional support for declarations. I have a suspicion that SBCL environments have been refactored in the last couple of years (I vaguely remember getting some errors when trying to refer to the environment value after the dynamic extent of the macro function, but I cannot reproduce the problem with fresh SBCL). Maybe in the process some of the bugs you describe in the tests have also been fixed.
On that note: I try to implement some clarifications in ECL. What would be useful is to have all extensions which can't be implemented as a user library in a common package (i.e CDR vs CDR-USER). I think this is not covered in any CDR (and having a feature that CDR-X is implemented doesn't give me much if I don't know in which package should I seek the new symbol).
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. My best-case plan includes codifying this approach, and making CDRs for other things from the same point of view. Thank you!