Code change:
that the epoch secret is confidential to the members in the current epoch. <del> For each Commit that adds one or more members to the group, there is a single corresponding Welcome message.  The Welcome message provides all the new members with the information they need to initialize </del> <ins> For each Commit that adds one or more members to the group, there are one or more corresponding Welcome messages.  Each Welcome message provides new members with the information they need to initialize </ins> their views of the key schedule and ratchet tree, so that these views align with the views held by other members of the group in this epoch.

Related discussion:
text: This updates the language around how certificate chains are constructed: We allow certificates to be omitted if the client knows any recipients will already possess the omitted certificate. We allow certificate chains to be out-of-order and potentially contain unused certificates. This is nice because it means less data needs to be sent on the wire, and also provides a method for root certificates to be rotated gracefully (as clients can provide chains for both old and new roots).
NAME it might be useful to also add this language from RFC 8446. It would make the process exactly the same as TLS which makes implementation easier. >The sender's certificate MUST come in the first >CertificateEntry in the list. Each following certificate SHOULD >directly certify the one immediately preceding it. Because >certificate validation requires that trust anchors be distributed >independently, a certificate that specifies a trust anchor MAY be >omitted from the chain, provided that supported peers are known to >possess any omitted certificates.
I think that is fine and is consistent with RFC8446. Don't we already have a better mechanism for rotating certificates? As soon as a member has a new certificate chain, it can update its LeafNode in an UpdatePath. This semantics of X.509 certificate bundles are already a bit fuzzy. Such a change will make validation more complicated and more error prone, when this seems completely unnecessary.
The scenario that this would address is: say that a root CA is compromised and needs to be replaced. Distributing the new CA certificate likely requires a software release, which not everyone will install simultaneously. During the rollout, some users will know only the old compromised CA and some users will know only the new CA and not the compromised one. To preserve interop during the rollout, users need to include two intermediates in their certificate chain: an intermediate signed by the old root that signs their leaf, and an intermediate signed by the new root that signs their leaf. (In the exact scenario I'm thinking of, the intermediate private key is held by the user, so it would not be compromised with the root. Though there may be other arrangements where this flexibility helps.) In terms of implementation complexity: the X509 chain validation libraries I'm aware of already support path building because it's necessary for TLS, so I would expect those could be used
This is actually the reason why I think it makes sense to adopt the same mechanism.