Change:
16.6. <ins> The "SignWithLabel" function defined in ciphersuites avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. This registry records the labels defined in this document, and allows additional labels to be registered in case extensions add other types of signature using the same signature keys used elsewhere in MLS. Template: Label: The string to be used as the "Label" parameter to "SignWithLabel" Recommended: Same as in Reference: The document where this credential is defined Initial contents: 16.7. The exporter function defined in exporters allows applications to derive key material from the MLS key schedule.  Like the TLS exporter RFC8446, the MLS exporter uses a label to distinguish between different applications' use of the exporter.  This registry allows applications to register their usage to avoid collisions. Template: Label: The string to be used as the "Label" parameter to "MLS- Exporter" Recommended: Same as in Reference: The document where this credential is defined The registry has no initial contents, since it is intended to be used by applications, not the core protocol.  The table below is intended only to show the column layout of the registry. 16.8. </ins> Specification Required RFC8126 registry requests are registered after a three-week review period on the MLS DEs' mailing list: mls-reg- review@ietf.org [1], on the advice of one or more of the MLS DEs.

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?