You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial?
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections?
Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system...
So let's imagine we're wise and we look forward and we structure the classes in Collections to play well with the category names in Collections, so that all the superclasses of classes in Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support that are themselves Collections classes are in just those categories. Now I can unload all Collections-blah categories except Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support. Because when I look at Collections I see that those six categories are those that provide the minimal subset of Collections that supports the core language's set of literal collections.
*You* can see that, a newbie couldn't. A newbie would have no way to know what all packages would be needed to simply have a "kernel" system. They would wonder why they couldn't just load "Kernel", huh? If the hierarchy for those would be reversed, as in, Kernel-Collections-Abstract, Kernel-Collections-Arrayed, Kernel-Collections-Exceptions, Kernel-Collections-Sequenceable, Kernel-Collections-Strings and Kernel-Collections-Support, THEN we've actually got a match between the newbie's semantic notion of a "Kernel" with the actual physical reality of what the system needs.
The top-level(s) of the category defines the Package. I don't believe this needs to be a compromise. Let the top-level(s) determine the package, based on *physical* dependency within the system, while the 2nd thru lower levels define the semantic (sub)categorical organization within the system.
It provides more, but it is the minimum to provide Array, ByteArray, ByteString, WideString, Symbol, ByteSymbol and WideSymbol.
Now, if that analysis is correct would it be better to change the package structure to have Collections-Kernel and Collections-PotPourri, with categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and so on, or have some other convention such as a class-side method on Collection that defines the kernel categories? I don't know. I do know that there's real pedagogical value in having the six (and other) categories above, and I don't think we should reduce the navigability and comprehensibility of the system to make package structure serve the needs of decomposition rather than the needs of the newbie. The bug is that packages use categories. It's a functional compromise, but it's a little uncomfortable. But the key point is that your point above about LRUCache is a bit of a straw man. If we manage the categories in Collections wisely we can do what you want without too much difficulty.