These are some thoughts on how we might have provided some of the serialization features that Mark Miller is designing for E. Keykos has system wide checkpoints and thus one of the motivations for serialization was absent and we had indeed not planned anything along these lines. It would nonetheless have been useful to move multi-object objects out of Keykos to be reinserted at a later time or different place.
We usually spoke as if most objects were composed of other objects but had no clear way of avoiding the linguistic traps this raises. For instance some readers are not supposed to know about internal objects, others are supposed to know, but not about which particular objects. This is an ontological muddle which seems to cause no harm, at least among the designers of the system. This muddle is like the one wherein a key is to one audience, a start key to a domain, and to another audience a key to a space bank.
If a domain creator dc had created a domain d and S was a start key to d then dc would convert S to the domain key to d. The owner of the code that the domain obeys probably holds dc exclusively. It would be possible to build a service SER that would take a domain creator and return a serializer that would serialize domains from that creator. The serializer would require a start key, or perhaps a resume key, and produce data, perhaps encrypted by a key known to the creator of the serializer.
When the serializer encounters a start key it would consult a can opener which was an argument to the creation to the serializer.
I see problems in negotiating membership in the confederation. It would presumably be possible to secede from a confederation by invoking the serializer.