An update for anyone following the progress of this feature.

I had sent some emails about implementing a slon-side wait so where we 
would record pre-condition events from other nodes. We've had some 
in-person discussions off list and have decided to go this route.

This leaves a handful of issues that the current ('wait until the next 
event node is caught up with the previous event node') approach.

In particular events that can be submitted at an arbitrary node such as

DROP NODE:
-We should wait for ALL pending non-sync events (from all nodes) to be 
confirmed by all nodes (other than the one being dropped) before 
submitting the drop node.  Otherwise an earlier event such as a 'store 
path' or even a subscribe involving the 'dropped' node might arrive at a 
fourth node after the drop node. This isn't a critical error in that the 
'new' row in sl_node will be an <event pending> node but that row will 
never go away and I think this will confuse people.

STORE SET:
-Can conflict with DROP SET, I drop a set from one event node/origin 
then create a set with the same id at a different node.  A third node 
might see the STORE before the DROP.   Before submitting a STORE SET we 
should make sure all outstanding non-sync events have been confirmed by 
all nodes.

A source of both of these problems is that we allow node and set id's to 
be reused.  Since I have no appetite to change that I think what I 
discuss above is the best option.  It does mean that you can't drop 
nodes or create new sets if you have another node that is behind.  If 
that is your situation you can always disable the auto-wait for feature 
and hope your behind node processes things in the right order.

There might be a few more cases that need this type of behaviour but I 
haven't pinpointed them yet.