Agreed. Common Lisp is extremely extensible; almost any language feature you could want can be layered on as a library. I'll offer FSet, my functional collections library, as an example. Functional collections were hardly known at the time of CL's creation -- SETL is the only language I know of that had them back then -- but I was able to graft them onto CL. Admittedly it took some thought and a few compromises, but the result is entirely usable.
(A functional collection type is one where each instance is immutable, but there are efficient operators to produce new instances from existing ones, e.g. by adding a new element to a set.)
From time to time I have thought that it would be nice to have a new version of CL without the historical warts (why is there no 'e' in 'makunbound'?), but that line of thinking inevitably leads to the conclusion that if I really want that, I should just make it a CL library. If it were a new, incompatible language, it wouldn't be able to run existing CL code, which would make it fairly useless even to me. And if it were CL-compatible, it wouldn't be any different from just a library on top of CL.
The only exceptions would be features that require deep implementation support. Multithreading is the most obvious example; it's not in the spec, but the major implementations added it years ago, and although their APIs aren't the same, there's a library that papers over the differences. High-performance firstclass continuations are the only such feature I can think of that hasn't been implemented, and there are very few applications that need those -- the only one I know of is a theorem prover I'm working on.
-- Scott