Change:
value provided by its peer. Definitions for each of the defined transport parameters are included <del> in transport-parameter-definitions.  An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR.  Any given parameter MUST appear at most once in a given transport parameters extension.  An endpoint MUST treat receipt of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. </del> <ins> in transport-parameter-definitions. An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR. An endpoint MUST NOT send a parameter more than once in a given transport parameters extension.  An endpoint SHOULD treat receipt of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> A server MUST include the original_connection_id transport parameter (transport-parameter-definitions) if it sent a Retry packet to enable

Discussion:
Changes a receiver requirement to, in , "senders: don't do that; receivers: you're not required to police but we'd really like it if you did."
I would prefer a middle ground, where I only MUST check for TPs I support. I can manage that, but tracking 65K items for duplicates is a bit much
Actually processing duplicates read to unpredictable behavior
I like this PR as currently worded. Checking should be encouraged but not mandated, even for known transport parameters.
The spin here is interesting. An endpoint should be able to track supported transport parameters. Also remember that once we start to approach 300 transport parameters, there is no more room in the client's Initial packet for other stuff (like keys). The server parameters don't have the same constraint, but you might reasonably assume that the same limit is coming.
I think I'm fine with what the PR says now. Though I'm also fine to see something like "the receiver SHOULD treat duplicates of TP that the endpoint supports as a connection error" being added. The issue with "MAY validate" in general is that it is sometimes hard for smaller players to enforce, because they'd be risking interoperability unless other players also enforce the behavior to the extent that the endpoints violating the requirement would never be shipped.
Perhaps a middleground could be: endpoints SHOULD validate (instead of the current MAY)? I like either as long as it's not a MUST validate.
the only thing I don't like about SHOULD validate for supported parameters is that if there are two copies the actual behavior is somewhat ambiguous. If I get two values for the same TP, which should I observe? Much cleaner to demand enforcement for supported TPs, IMO.
I could live in a world that requires MUST validation of the small set of IANA registered non-GREASE transport parameters (and tangentially HTTP/3 SETTINGS parameters). I don't want to "MUST validate" a humungous set of parameters.
If it's MUST not send and SHOULD validate, then I believe there's no need to define what happens if multiple are sent, because it's explicitly forbidden.
Ok, I've changed it to SHOULD error if dups are received, and I've explicitly called out MUST NOT send.
Although I'd prefer a MUST for the non-proprietary TPs, I can live with the current PR.

Unlike HTTP/3 settings, receipt of : Why the inconsistency? The checks for duplicated transport (or settings) parameters are expensive, because one has to maintain an arbitrarily-sized set of possibly large numbers. I propose we switch the duplicate transport parameters enforcement to "MAY treat as error."
I'm fine with MUST not send duplicates, MAY treat receipt as an error.
Fine by me.
Yup, seems sensible to me.