Tim suggests:

> There are some bits available in the method headers  (or at least 
> there are if
> you use my NewCompiledMethod images) and one or more could be used to flag a
> method as private. The message sending code could check this flag and
> subsequently test the current reciever against the putative reciever of the
> message being sent. If they do not match, do something like #cannotReturn (or
> better yet do a proper exception raising) and work out what to do next.
> With several flags available, we could even consider reifying the several-
> levels-of-privacy idea Carl mentioned.
> The flag checking could conveniently be done in the cache loading routine and
> if we took the opportunity to 'fudge' the apparent primitive index we could
> essentially detect the private flag(s) at no cost in
> [internalE|e]xecuteNewMethod. Simply detect a primtiveIndex of some 
> ludicrously
> high number. By ORRing the flag into theprimitiveIndex we can keep the 'real'
> primitiveIndex if any is needed for the method.

Isn't the idea to avoid things that increase the overhead of message 
send?  Is the feature of precluding primitives at runtime (since 
compile-time is relatively straightforward) so valuable a feature 
that it justifies a separate check against a method header flag for 
EVERY uncached message send?