Change:
endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in <del> NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </del> <ins> NEW_CONNECTION_ID frames.  The value of the active_connection_id_limit parameter MUST be at least 2.  An endpoint that receives a value less than 2 MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR.  If this transport parameter is absent, a default of 2 is assumed.  If an endpoint issues a zero-length connection ID, it will never send a NEW_CONNECTION_ID frame and therefore ignores the active_connection_id_limit value received from its peer. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,

Discussion:
Purely editorial nit: This text has a lot of line breaks that won't render as such in the output. If you want to have separate paragraphs in the definition, you need a new for each new paragraph.
In the description of activeconnectionidlimit, we require that the server make the value of the transport parameter conditional on the choice of connection ID from the client. In the past, we have had the principle that either endpoint not condition its choice of transport parameter values based on anything from its peer. We should maintain this principle throughout. This means changing the definition of activeconnectionidlimit; NAME had a sense that there was another.
I'd like to understand what your argument is here. Is it that you must not condition your response, or merely that it is not necessary to. For instance, you suppose we have a set of extensions that exist and that those extensions need to be jointly agreed on whether they will be done. The client supports some set Ec and the set of extensions Es. The client clearly sends Ec. Is your argument that the server must send Es and not Ec cap Es and the client must compute the intersection? Or that it might send either?
My understanding of the argument is that we shouldn't force servers to condition their TPs based on the client's Initial packet (possibly including TPs). E.g. the server currently needs to condition its activeconnectionidlimit TP based on whether the client's Initial had a zero-len SCID; PR relaxes that constraint. Assuming we have some future sets of TPs for extensions (and these TPs are advertised values, not negotiated values) Ec on the client and Es on the server: The server could always send Es (so it doesn't have to condition its response), or the server could send Ec cap Es, and in either case the client will ignore values sent by the server not in E_c. For future extensions that have negotiated transport params, the server will have to condition those values based on what the client sent.
MAY send a fixed set (so MAY NOT condition the response I guess) or that it is not necessary to. So managing intersection of incompatible extensions is one case where conditioning might seem to be necessary, but that can be resolved by establishing precedence for instance.
I looked through the existing transport parameters for what currently conflicts with a fixed profile of transport parameters.

I've only found one (apart from the already discussed activeconnectionidlimit): originalconnection_id. This field is necessarily dependent on what the client sends. The only way to avoid this is to not send Retry packets so you don't need to send this TP. The rest of the transport parameters appear to be independent of what the peer sent.
What about statelessresettoken? I doubt many servers would send a static value (or not send it at all).
NAME Where did we use this principle in the past? I can't remember that we said anything like that. Since we're using transport parameters to negotiate extensions (and extensions might use the value of the TP to negotiate something), I don't think this is a viable principle to follow.
NAME IIRC the most recent occasion that we discussed this principle is when we changed the name of to . The reason we changed the name was specifically due to this principle. Each endpoint declares its maximum, instead of conditioning its value on the others. That's why it's now called max-idle-timeout, and why we require each endpoint to calculate the minimum of the two.
My understanding is that the principle was you shouldn't be required to condition TPs based on data from the peer, not that one is precluded from doing so.
I guess that "fixed" is the wrong term. More to the point that the transport parameters don't necessarily depend on what a peer does. That accounts for the stateless reset case, because that only "depends" on local choices.
I think we need to see more (supportive) discussion in order to justify taking this on.
I don't know that there's much here to "take on" beyond clarifying what our design principles are, and maybe writing those down somewhere for designers of future transport parameters. The principle here is that TPs are independent declarations by each side, not negotiations. I've noticed as we get further and further into this process, we have a number of principles which haven't been written down which have guided our design -- and we keep revisiting them because only the resulting design is explicit. I'm wondering if those principles belong... somewhere. An appendix, a published draft, etc. even if not enshrined in an RFC.
I agree with Mike.

I noticed we already state this design principle in section 7.3: "These declarations are made unilaterally by each endpoint." Taking on/resolving this issue brings transport parameters back in line with the stated property of them being declarations, not negotiated. I think this is a worthwhile change.
The current language defining the activeconnectionid_limit transport parameter refers to "a zero-length connection ID is being used". It's unclear whether the zero-length CID is the CID of the sender of the TP or the receiver of the TP. Since this TP limits how many CIDs the peer can send, the references to using a zero-length CID only make sense if it's the peer using a zero-length CID, but it would be useful to clean up that language. I've created PR to clarify this language, including that checking whether the peer is using a zero-length CID can only be done by the server.
Chairs, the fix here turned out to be more complex. Let's get wider review for this.
LGTMLGTM, modulo one suggestion.