as: OneOfMySubclasses
         ^self shallowCopy changeClassTo: OneOfMySubclasses

changeClass: can only work if the object has the right number of fields
for the class its becoming an instance of.  If a class has indexable
fields then any object changing class to it must has at least as many
fields as the class.

So assuming your two classes are not indexable you can't use shallowCopy
followed by changeClass because the copy will have one inst var too
few.  If you do want to use changeClass (because it is indeed quite
fast) you'll want to declare the inst var in the superclass but only use
it in the subclass.

The alternative would have been to copy each of the instance variables in code
from one object to the other. I'm assuming #shallowCopy/#changeClassTo: is a
relatively speedy process.  Does anyone know that it isn't, or if there's
speedier alternatives?

obj changeClassTo: Array.
x := Array new: subclassSize.
copy obj into x
x changeClassTo: subclass.

Why not just use a simple wrapper object that holds the persistent
EfiReceipt and the non-persistent instVar.  Relying so heavily upon
inheritance that you must perform serious meta behavior should be telling
you that you should revisit some design choices.

Just my 2 cents.

All of my objects know how to handle printing themselves on a stream in XML.
This includes printing their key, complete with their parent's key, data
sections, attributes, etc.  A wrapper has to implement a bunch of DNU stuff
(OK, one DNU thing) so that the object will XMLize itself as expected.  In
this specific case, I'm creating the subclass so that the copied object can
have attributes it's original knows nothing about.

In this case, the attribute is an instance variabled called 'score', which is
transient and doesn't need to be stored.

Is it really wierd to use meta behavior for this kind of thing?  In an object
oriented system should it be an extraordinary event for one object to project
itself (or masquerade) as one of its subclasses?  Or should it be odd for a
subclass to be created to add transient methods or data from an ancestor?

Personally (and I haven't been doing this too long so I may be in left-field)
I think it would be unwise to add the variable to the original class and use
under-the-hood database stuffs to indicate the variable is never stored (or
shouldn't be, at least).  Documenting the slight-of-hand would attempt to make
obvious something that's is implemented in an unobvious way--whereas the
alternative appears suspect because of the unsavory company it keeps--meta
class behaviors?

As I mentioned before, I had at one time (only a few weeks ago, actually)
something called EfiObjectProxy which had a lot of the EfiObject (the parent
of almost all my classes) redirected to the wrapped class.  But trying to get
the wrapper object to intermingle its XML with that of the wrapped object
indicated to me (by the amount of effort involved) that there may be a more
direct solution.

From an XP perspective do the simplest thing that could possibly work
(but no simpler).  And from what I can infer, the inst var in the
superclass is much simpler.  But as soon as it becomes too simple rip it
out, do it the simplest way now, and if feeling a little neurotic, cast
around for a validating aesthetic.

There is no single right way to do anything; there are only trade-offs.
Know your constraints and limitations so that "simplest" is evaluated in
the appropriate scope; its not just a matter of the code its also its
maintainability, migratability, etc, etc.