Eliot,

thanks for all your wonderful comments and insights about the Parcel
system in VisualWorks. My experience with it is extremely limited (I
once loaded idass, the chip simulation system, as a parcel into VW 5i
NC) and so I cited V/Win as an existence proof.

You are correct that an object table wouldn't help in general when
comparing two images - I was thinking of the specific case of when one
is known to be directly derived from the other like Squeak 3.8 from 3.7.
This was from the discussion of doing a security audit to allow Squeak
to be included in Debian. 
Comparing unordered collections has all the complications you mentioned
and in Smalltalk this is supposed to be solved in #=, which experience
tells us not to trust too much.

For Neo Smalltalk I didn't do pure memory dumps but had a binary format
that was reasonably compressed. And it didn't have small integers but
only variable sized ones and these became SmallIntegers or LargeIntegers
when read in. That made the binary format compatible between the 16 and
36 bit versions of Neo Smalltalk.

One idea for Neo modules that Dan thought a bit excessive was to divide
each into four related modules: the actual objects (I'll call this the
"deployment module" to use your term), the sources (just a bunch of
String objects), the documentation (nicely formated text, with possibly
pictures or even movies) and the tests. In different situations you
might want different subsets of these. For example, while browsing
through SqueakMap you might click on "see more..." and get the full docs
in your machine. Then you might click on an example and create a new
object (in a new module) that would bring in the deployment module to
support it. If you ever try to look at the code for this new object in
the system browser or the debugger then the sources module would get
loaded. There would be links to the tests in the documentation but they
might also get loaded through the SUnit tool. If you close all windows
with the documentation, the doc module will eventually be unloaded.

Of course, I am supposing that objects in a module can point to objects
in a separate module in the above description. And that module
loading/unloading is a kind of crude virtual memory.

-- Jecel