Hi Craig,

>       Indeed, none of our code should be proxy-aware.

I certainly would agree with the statement, "it would be nice if none
of our code needed to be proxy-aware," but I don't yet understand how
it's possible, regardless where the implementation details are handled
(VM or image).  As a VM expert, I can appreciate you preferring to use
VM-based proxies.  The only downside is that those who only understand
Smalltalk and not the secret innards of the VM cannot realistically
participate in Squeak anymore if they wish or need to use the classic
Proxy pattern.  We broke the code and also legacy systems for that.

Which is why I keep bringing up just this one example on Symbol
and hoping someone can explain it to help me get unstuck.  Would you
follow its code with me, line by line, below?  Let's pretend the
receiver is the symbol #size, and the argument, aSymbol, comes in as
an instance of MyProxy, which refers to an Integer oid that ultimately
will reify to the receiver object (#size)).

It's easy to see why the code no longer works for the traditional Proxy pattern:

   = aSymbol       "<------ aSymbol comes in as a MyProxy instance"
        self == aSymbol ifTrue: [^ true].       "<---- false, continue"
        aSymbol isSymbol ifTrue: [^ false].  "<----- true, return false.  BUG!"
        "Use String comparison otherwise"
        ^ super = aSymbol

So what about when aVMProxy instance is passed in?  I'm so used to
normal Smalltalk-think, I'm not even able to think about WHEN or HOW
the VM would perform it's magic handling of the incoming VMProxy
instance to make this work.  I guess this is a trade-off -- we don't
have to think about Proxy's, but we have to know about and think about
VM magic.  I'm willing to try, but I don't even know where to begin.
Would you help?

Regards,
  Chris