I based this sentence on what Drew Crampsie said:

"We will also _not_ be deprecating things from CL because they are
bizarrely name or parameterized."

Just renaming functions or creating a new package with more "orthogonal names" (whatever that means) does not include any new feature nor functionality in the language and it is something you can do yourself. It falls into what was already said: that it is not one of Cltl3's goal to make CL more readable or easier for newbies or whatever. It also depends too much on personal taste. Having one function with different names makes more confusion than clarification.

Such a thing pollutes the packages with names you are not going to use. For instance, I might not like some naming conventions in COMMON-LISP-3 or I might have some code that already uses CL's standard names, so I decide to import from both packages COMMON-LISP-3 and COMMON-LISP. Then I will have to manually shadow all symbols that I don't want to use, or I will be obligated not to use those names in my package.

Not to mention that doing this will make it look like that we are trying to force people to program in a different language, learn new names or new parameter orders. This is very different from including extensions - you may safely and easily just ignore such extensions. Maybe in the course of discussion we end up creating functions that are generalizations of other functions already in ANSI CL, then it will be ok to deprecate those functions, but this is very different from just creating aliases.

And, as a mater of fact, I can't imagine how to implement versioned packages in a way that its cost is below its benefits. I can only imaging that something in this direction will need big changes in implementations for only providing a small benefit, or to occupy more space (many versions of the same functions). I will be glad if someone proves me wrong. Conduit packages look much more useful than versioned packages.