Right, cleanup stuffs like I started off with would be easy enough to do now. And reasonably common extensions are covered by things like Alexandria. But going to more generics introduces a potential performance hit without the implementations being onboard to improve how they handle generic functions and method dispatch. And then there are other enhancements (like concurrency) that are bounded, with regards to portability, by whatever implementations uniformly make available. So any changes there will require implementations to be involved if it's going to result in portable code. Otherwise you'll have people implementing things using, maybe, CFFI and tying it to a particular implementation, OS, and set of external libraries, which breaks portability.

I'd argue genericizing a built-in won't impose a performance penalty on anything it currently is required to do. That's because it already has to dispatch on the classes it does handle, and also should recognize and error when it's given a class it doesn't. Adding more cases just means replacing the old error case with more decisions (if dispatch is implemented by a decision tree), or expanding the hash table (if dispatch is handled by the usual CLOS dispatch table.)

There is a general philosophy in the design of Common Lisp: expose to the user facilities that are used by an implementation for the implementation of built-ins. I don't think Common Lisp is quite complete in this respect, but this would be the place to extend it.