To which this question is raised:

Is it possible to have a common tie-breaker process and force the
loser to rebase?
That is, if the change c->c' wins, then d needs to apply their d->d'
change again on top of that change (or move to d'').

.. and responded to by katriel next:

Yes, I think so. Another one would be "the person who has least recently done an update wins ties", which would help with starvation issues. As you point out, the downside is that endpoints might have to keep quite a lot of potential state around in case an old message comes through and requires a large rebase.

I was wondering whether you could have a cap like "never rebase more than five updates ago" or something to prevent that case, but the challenge there is that without a centralised server you don't have a consistent view of how many updates have actually happened. The particularly problematic case is when e.g. A and B do a whole bunch of updates, and then C comes in and preempts them.

Having a centralised sequencing server makes this whole problem go away, sadly.