Sorry for a one-week dated response on this, I've been buried with work
recently.

> It would be possible, and useful, to do much more sophisticated things 
> than this.  Each object in the database knows exactly what the layout 
> of its class was at the time it was stored, so that you could in theory 
> set things up so that every time an object is loaded, it goes through a 
> transformation defined for the specific old/new class layout pair 
> that's relevant.

This is exactly the approach that Magma takes, or *tried* to anyway, by the
user specifying an "upgradeBlock" that implements a transformation that are
supposed to occur version-to-version.  The problem is, I never got around to
supporting persisting Blocks, so the default block just leaves new variables
nil.

But while working on Magma 1.0gamma8, the primary improvement of which is live
class-evolution, I decided to get rid of the upgradeBlocks entirely.  I
discovered I liked the standard behavior to just leave unrecognized vars nil
for its consistency with Smalltalk, and that it doesn't try to solve a problem
the solution to which is, IMO, totally dependent on the situation.

But I still agree with Avi that, to survive in a world of old, persistent,
distributed objects, an approach that favors backward-compatibile-code will be
required in many situations.

 - Chris