Change:
Add and Commit message adding that member, and broadcasts them to the group.  It also generates a Welcome message and sends this directly to the new member (there's no need to send it to the group).  Only <del> after A has received its Commit message back from the server does it update its state to reflect the new member's addition. Upon receiving the Welcome message, the new member will be able to read and send new messages to the group.  However, messages sent before they were added to the group will not be accessible. </del> <ins> after A has received its Commit message back from the Delivery Service does it update its state to reflect the new member's addition. Once A has updated its state, the new member has processed the Welcome, and any other group members have processed the Commit, they will all have consistent representations of the group state, including a group secret that is known only to the members the group. The new member will be able to read and send new messages to the group, but messages sent before they were added to the group will not be accessible. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download a KeyPackage for a new client and

Discussion:
Comment by NAME Citation needed? I think most phones have AES(_GCM) in hardware too ? Also compared to HPKE operations and the times for epoch/group reinit, does this performance really matter? (eg waking up from sleep to increment the epoch would make the symmetric encryption cost pretty irrelevant. I would remove this sentence.
I'll remove the "mobile processors" bit and phrase it a little more evenhandedly ("can choose ChaCha or GCM"), but I think it's fair to say that there might be environments where ChaCha/Poly is more performant than AES-GCM.
Thanks. I do think you might be right that "there are", but I also do not think "mobile" is that :)
Comment by NAME This sentence with a hidden MUST is stuck between a sentence with MAY and a sentence with SHOULD. Perhaps make the MUST explicit ?
This is already well covered in the discussion, but I can add a cross-reference.
I meant just rephase the sentence so it contains "MUST delete when the epoch ends"
Comment by NAME That is quite some information that must be publicly available to allow external Add requests. This leaks information, eg same epoch means the group membership did not change, etc etc. I hope this will appear in the Security Considerations later :)
I suppose between this and , we should add a subsection to the Security Considerations on metadata privacy.
I'm not sure actually resolves this?
Oops, that's correct NAME Had it in my notes among the others.
Comment by NAME Isn't there technically also limits to how much one AEAD key and one nonce can be used to encrypt a (very very) large message? I guess this could not happen, but is there some formal message size limit in MLS ? (looking at the vectors at the start, limits could be higher than 2^64 ?)
Comment by NAME Another weird MAY here. Again, I would just lowercase it as this is just a pointer to a human decision, not a 2119 based protocol enforcement.
Comment by NAME Figure 10 claims to have seven members, but I count 8, namely Y,T,X,A,B,E,F and G (not counting W, the root)
Actually, it only has five! A, B, E, F, and G. Recall that members are at the leaves of the tree.
Ah right :)
Comment by NAME This MAY is super weird.

Is it allowed to implement in such a way that they to NOT produce correct protocol messages? :-) Remove the entire sentence or lowercase the MAY?
Comment by NAME What server? The Delivery Service ?
Comment by NAME Should this be "prospective member" or "invitee" ? They haven't joined yet, have they?
From the perspective of the group, they are joined. Once the Commit adding the new member is processed and the new epoch starts, that member is able to access the group's secrets. The only thing "provisional" about the membership is that the new member hasn't initialized their local state. We use "new member" consistently to mean the subject of an Add proposal, and I don't think this is a big enough distinction to merit more terminology.
Another way to look at it is that keying information from the new member is already incorporated into the group, therefore they are a member and not a provisional member.
Ah yes. Perhaps a single line explaining this at the quoted location could be useful, but is not required