> That's pretty much the opposite of what I was saying.
> #removeFromSystem: is something wired fairly deeply into the guts of
> the system.

Not very deep, and there aren't that many senders.  They could be
changed to use the new #primRemoveFromSystem:; but how much would you
like to bet they don't expect there to be subclasses.  IOW, eToys or
Kedama generating classes dynamically, and then later removing those
classes as part of an app function; they are not creating subclasses
of *those*.  I don't think any sender of removeFromSystem: wants to
keep subclasses.  If they do, I'll be interested to understand why.

It's wrong to have a method which leaves the domain (in this case, the
class model) in an invalid state be named what the first thought
someone would have, looking for such API.  #removeFromSystem: is the
correct name for the behavior users expect.  #prim is the appropriate
prefix for the behavior users don't expect; that potentially leaves
the domain in a partial or invalid state.  The #prim method should be
private.

> But OK, try it out with unloading MC packages. Let's see
> if it blows up. (I anticipate seeing a bunch of unexpected behaviour
> resulting from MCClassDefinitions having their classes ripped out from
> under them, and possibly weird behaviour from classes being #unload-ed
> multiple times during the unload process.
>
> Specifically, given
>
> Object subclass: #Foo.
> Foo subclass: #Bar.
> Bar subclass: #Baz.

Sure, please try it out and if anything blows up or is otherwise wrong
in some way, we'll either fix or abandon this idea.

> I expect to see Foo unloaded once, Bar unloaded twice, and Bax
> unloaded three times. That does not seem right to me.

I agree it would be wrong if it were true, but I'm not seeing how it
is.  What do you mean "unloaded three times"?  Are you saying you
think #unload will be called three times on Baz?  If that's true,
you'll get no argument from me about that needing fixed.

> But I repeat: I think it's a great idea to have cmd-X say "yep, that
> class is gone" and "oh hey, do you want to remove the class and all
> these here subclasses?" (a bit like like removing a method does) in
> the tools.

There is already a short and sweet message warning about there being
subclasses.  Your proposal to list every subclass would turn that into
a large and elaborate confirmation pop-up.  It would be presenting
information that was directly under it in the original
HierarchyBrowser, and better viewed there anyway.  So, the user who
didn't know what they're doing will most likely just press "No" and
see it there.

Pop-ups are evil.  Until we can eliminate them entirely, I prefer to
keep them as low-profile as possible.