Code change:
Okay I made another pass on the text based on NAME comments, however, it didn't get any short but maybe it's slight more clear now. Please re-review! (Also I moved some paragraphs around to improve the text flow; so the PR now looks bigger than it is. So we also need to update the section title now, which is "Port Selection and Application Endpoint Discovery"?)
Applicability Sec 8: >Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC >itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. I was going to start a discussion about this at IETF 111. I think we should think hard about this; if there are a lot of versions with small differences to the application, this could result in a ridiculous cloud of RFCs.
Is there a change to make to this document in WGLC, or is this a note to be careful in the future?
I personally don't like this linkage, and think the ALPN should just define the application. While linking the version does smooth out version negotiation, it can result in an explosion in the ALPN registry. I'll start a thread on the list about this, since I suppose it can't wait for the discussion at 111 that I was planning.
The point this was discussed already at length and the manageability document is just reflecting what has been decided for h3. So if at all you'd need to raise an issue on the h3 draft but I guess that's also too late.
I disagree that the text of the H3 draft mandates this: That is a long way from saying "roll a new ALPN for each QUIC version". Maybe everyone tacitly agrees we should roll a new ALPN, and I'm in the rough. But I'd like to confirm that.
See quicwg/base-drafts
How about rewording the sentence to reflect reality, roughly Since QUIC v1 (RFC9000) deferred defining a version negotiation mechanism. HTTP/3 (RFC-to-be-whatever) deferred deciding how it would map to other QUIC versions. HTTP/3 requires QUIC v1 and defines the ALPN token ("h3") to only apply to that version. This solves a versioning problem at the cost of future flexibility. Application protocol mappings written for QUIC v1 or other QUIC versions may be able to benefit from version negotiation mechanisms that did not exist during the development of HTTP/3 (RFC-to-be-whatever). Coupling QUIC version to ALPN tokens is one approach but not the only approach.
I believe the text already says that this doesn't have to be applied by other application. The cited text is really only meant to described what was decided from h3 as an example. We can definitely reword this for reflect the consensus more clearly as proposed by Lucas.
Lucas, I would welcome your proposal as kicking the can down the road and not enshrining an approach that I think is bad. I would also like to continue the ALPN/versioning discussion, but it doesn't have to block the applicability draft.
I can make it shorter. Maybe not as short as NAME would have it, but still shorter :)

Related discussion:
text: network elements such as firewalls that use the port number for application identification. <ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" Application-Layer Protocol Negotiation (ALPN) RFC7301 token. ALPN permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered.  Applications using QUIC are required to register an ALPN token for use in the TLS handshake. As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version.  So far no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general.  Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions.  Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3. </ins> 9. QUIC supports connection migration by the client.  If an IP address