Even cleaner than mine! I agree that they are philosophically similar in-so-far as both prevent the creation of unrectifiably divergent update histories, but it seems only causal invariance guarantees the creation of a single thread of history.

Just for completeness, since my example is less constructed, here is another case showing confluence doesn't imply causal invariance. In this case, the rule contains exact inverses, so it is confluent (indeed by applying the second rule repeatedly, you can always return to the single loop state). However (and here is the reason I didn't post the example first), one can show that the causal graphs generated are all non-isomorphic, and indeed, one can read off exactly the sequence of rules applied by taking the unique longest path in the graph (the one that connects all update events in order) and then counting the in-degree (in-degree 1 -> first rule, in-degree 2 -> second). It takes an argument now (assume there is an isomorphism, look at a neighborhood of the image of the first point in one graph in the other derive a contradiction unless it is also the first point on the second and induct) to show that this proves that not only are they not always causal invariant, but indeed no two distinct update orders ever produce isomorphic graphs.

Indeed---as I said, your examples are more more to the heart of the matter! The isomorphism class trick seems to just be a bandaid to me since if you just extend the rule I stated to throw off "dust" of disconnected hyper-edges with each update, this keeps track up update steps and explicitly breaks the isomorphism class fix while keep the exact same causal graphs as before (even to the degree the same causal graphs are generated for the same seed by your code ;) ). I'd be willing to bet you can pretty generically break isomorphism classes without breaking confluence.