> > Nothing more than serialize the requests, first come, first serve.  Two
> > adds of the same object results in having two pointers to it from the mc
> > (think Bag).  Requests for removal of absentees are inhaled silently.
> 
> But how is this implemented?  
Requests are queued by the "Ma client server" framework and passed to the
MagmaRepositoryController, one at a time.  For a CommitRequest, a
"CommitPackage" contains a bundle of changed objects, including any additions
and removals to MagmaCollections.  BTW, by the time a CommitPackage reaches the
server, all objects are defined only in terms of Integer oids, there are NO
domain instances on the server.  The entire CommitPackage is first checked for
conflicts (see MaCommitLogEntry>>recordObjectConflictsIn:) and, if none,
written to disk (see
MaObjectRepository>>writeAll:recordPermenantLoidsInResultFor:).

> I guess MagmaCollections special-cased by the transaction system?
Yes, MagmaCollections are special, there is some special-case code to support
them.

> If I wanted to implement my own conflict-reduced class, what would I have
> to do?
The answer, of course, is "it depends."  There are no "hooks" provided that are
intended to do this, if that is what you're asking.  You would have to enhance
the server code to support it.  

Stephen Pairs suggestion for Chango sounded interesting!  Currently, the Magma
server doesn't require any of the classes it persists to be defined in its
image.  It only deals with object "records" (actually called "buffers") that
describe object relationships solely in terms of Integer oids.  This helps make
for a lean server, which contributes to good performance.  So any
"ConflictReducerDefinitions" would, like ReadStrategy's, need to be defined in
terms of the class Id's that need the special conflict-reduced behavior by the
time they reach the server.