Here's a new way in which putting SEQUENCER below GMS is broken.

Start with A having view B|4 [B,A], while B, C and D all have view B|7 [B,C,D].

Now we start a merge, in which B is coordinator. B creates the view C|8 [C, D, A, B].

(I've opened a pull request saying that B surely shouldn't issue a view where the ViewID says that C was the creator. But I think that this is incidental, and not key to the bug that I'm reporting here).

Now B sends INSTALL_MERGE_VIEW to B (a coordinator) and A (a merge participant, per Util.determineMergeParticipants).

B gets this first and broadcasts the new view to [B, C, D]. In particular, B is now not a coordinator.

Then A gets the INSTALL_MERGE_VIEW, and it too tries broadcasting the new view. SEQUENCER gets involved, and forwards the broadcast to B (as the coordinator in the old view). B discards this; it's no longer a coordinator.

So the new view is not installed at A. All future broadcasts from A are forwarded to B, who discards them. The group is fractured, and none of A's broadcasts are delivered.

I'm not sure what the right fix would be. I wonder whether things should be arranged so that in a merge:

• coordinators behave as today, broadcasting the new view to their own sub-groups
• but mere participants do not do this: they should just have the new view installed on them.