this reply to the OP above does a nice job of explaining the problem matthew pointed out:

The problem is from the ratcheting tree construction: two updates which
both want to change a particular intermediate node cannot both be
applied at the same time.

and then some..!

Not the problem

One thing I should highlight up front is that this does not necessarily
prevent decrypting messages, only applying key updates. Specifically, if
A receives either C's or D's update they can apply it and compute the
resulting root key, then decrypt the message. Of course, if the update
is one that should have bounced, then they might have to "un-apply" it.
Moreover, if A wants to send their own update, they need to pick one of
y' and y'' to base it on. This is something I don't think we've reasoned
about in detail yet.
For other reasons due to malicious group members, I think we're likely
to come up with a system where each participant has various "proposed"
updates sitting around, and then only confirms them after receiving
some other message. This sort of algorithm should also help here,
because I think it will also need the ability to unwind or not apply a
potential update.
Another thing is having the server do some clever re-ordering. The
challenge is that in the end, by construction the correct value of the
intermediate node should only be computable by its children, so there's
only so much the server can do.
For the same reason, I'm not sure the server can unilaterally rebalance
the tree; I think it would need some help from one of the participants.
I'd have to think more carefully about the precise keys which it would
need to do so, though. In particular, if you are more worried about re-
ordering join events than re-ordering key updates, there might be some
specialised tricks that work.

Things we tried that don't yet work

...
Another thing is having the server do some clever re-ordering. The
challenge is that in the end, by construction the correct value of the
intermediate node should only be computable by its children, so there's
only so much the server can do.
For the same reason, I'm not sure the server can unilaterally rebalance
the tree; I think it would need some help from one of the participants.
I'd have to think more carefully about the precise keys which it would
need to do so, though. In particular, if you are more worried about re-
ordering join events than re-ordering key updates, there might be some
specialised tricks that work.