Is everyone missing this or what?  There is a *huge* difference 
between what has been proposed and transactional computation.  
Transactions require Atomicity, Consistency, Isolation, and 
Durability.  What has been proposed is just Atomicity.  Period.  
While that is a very useful thing to have, it's never  going to 
be enough.

To use a dead simple example from the current domain, how do you 
transfer funds from one bank account to another?  Without all 
four of the above properties, there is no reliable mechanism to 
do so (it might be possible with only three, but I'm not 
certain).

Within the main proposal of serialized processing of incoming 
messages, it seems that there is a subpropsal for a design 
pattern that says these messages should be commutative.  Good.  
The Scamper example can probably be expressed in a simple state 
machine, and (limited) commutativity can be ensured by ensuring 
the state machine is fairly complete and well-defined.

The advantage of commutative operations is that you don't have 
to care what state the target object is in at the point in time 
that you send a message.  If you're incrementing a counter, 
it'll get incremented whether or not other increments have been 
processed.  You can even have a linear "set" operation that 
writes a value and sends back a message containing the old 
value.  That will let you build up nice properties like 
"Conservation of Money", which accounting systems simply *have* 
to have.  A language with linear types could even support such a 
concept *provably*.