Author here. Happy to answer questions!
For your normal end user (at least what I think of as common: see how facebook messenger works, as well as slack, discord and even how many irc chat rooms have public logs), how is this MLS scheme useful?
2. I'm not sure what gives this impression? I have a server that is very much on flaky network, and it federates just fine. The point is that servers can go online/offline without breaking anything on the whole network.
Firstly, no need for sender keys. A single group key will do. When you remove someone from the group, you still do the group update and derive a new group key (unless you don't want post-compromise security either, in which case you can throw out the entire tree concept).
Now when you add someone to the group, you share with them the entire historical group transcript along with all the previous group keys.
Is this roughly what you're looking for?
Presumably this isn't done because the additional messages required to do this defeat the gains?
I don't think anyone has to update their keypairs if they get promoted. They would only get promoted if their sibling is blank. In that case, they can just take their parent's keypair and not worry about anyone else having it.
[0]: https://trailofbits.files.wordpress.com/2019/08/post_remove_...
[1]: https://trailofbits.files.wordpress.com/2019/08/image1-1.png
Say you want to prove you are a member of the AMA or IEEE, or Bar? Could you set up a large group for the association and their communications, and then when asked provide verifiable credentials that you are a member? Like a group membership signature?
In solution #2, when an encrypted message is received, does the receiver have to lookup the sender's specific key from a list that they maintain? In other words, does every member have a list of every other member's special group keys?
This is more or less equivalent to having a single shared group key, but there are some practical reasons why it's split out. I think one of them is that it makes symmetric key ratcheting (for the purposes of perfect forward secrecy) a little less disastrous in the case of out-of-order or failed message delivery. Not totally sure, though.