>> Unless we decide to tightly couple both packages, we either require "self
>> respondsTo:" or an override extension from System to Kernel.
>
> Or we do a proper job of working out an effective way of doing this. I really hate to see (ab)use of #respondsTo:  like this. Surely it must be slower than simply sending the message

Probably not a discernable performance issue for releasing resources.

I do agree that respondsTo: is nothing to be used liberally, but it
does exist, and there are cases where Smalltalk's ability to
"optionally send a message" is a perfectly simple and appropriate
solution.  It creates no mysteries.

>  - allowing the VM to do its normal fast lookups and caching - and occasionally having to catch a dNU: ?
>
> If that is a practical path, then we need to imagine some simple and comprehensible ways to
> a) catch the dNU and do.. whatever
> b) discover that the catching is needed, which seems like some sneaky package analysis stuff well suited to a PhD student
> c) find a way to use a & b without pissing off the general user/coder

IMO, the above and the other "cures" proposed such as introducing a MC
override are much worse than the "illness" -- this single use of
#respondsTo:.

Squeak 5.0 release was delayed for 2 months because of a crazy package
tangle due to an MC override.  Do we _really_ want to cross that line
from having an override-free system to one with overrides because of
one little optional message in the code?

Forgive me:  ;)

   https://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face