The highlighted comment was created in this revision.
By "broadcast scheme", this refers collectively to the peer-to-peer pairwise broadcast, or the "sender keys" optimisation on top of it. I think "broadcast scheme" is too generic and confusing. How about "p2p-broadcast", "full-broadcast", "sender-broadcast", or "member-broadcast"?
I also disagree with "Each participant will have its own different $plist_i$ which is able to broadcast too.". In all schemes, every member should eventually reach the same plist as everyone else. In all schemes, there will be a period where different members have different plists - e.g. even in the GKE case, some members will receive the final round of the GKE earlier than others, so switch to the new plist earlier than those others.
The key difference is that in the p2p-broadcast case, (optionally) members are able to *provisionally send* to the new plist earlier than some other members do, without receiving a key confirmation (and with a forward secrecy penalty if there was an active attack).
I don't think any of those schemes are fundamentally different. The fundamental difference in threat model (and in implementation) is can we start sending message before everybody a reach same view of the room or not.
Original mpOTR doesn't allow it and it is much simpler in implementation and we have security proof for it. My guess is that it doesn't make a huge difference in user experience in majority of xmpp usages. It is also not hard to tweak the code and algorithm to fall back to the different view scenario, that is why I prefer to go with that.