Change:
multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support.  This ensures that the server responds if there is a <del> mutually supported version. </del> <ins> mutually supported version.  A server might not send a Version Negotiation packet if the datagram it receives is smaller than the minimum size specified in a different version; see initial-size. </ins> 6.1.

Discussion:
It was not clear to me that the current text was insufficient, but hopefully this is more sufficient.
I think enough opinions suggesting that we don't need this might lead me to close the PR over Gorry's objections, but I am sensitive to the fact that most people here are perhaps a little too familiar with the protocol already.
Cross references are cheap.
(Broken out of .) Are you saying a client that does not PAD does not negotiate? If so: What is the logic behind that design decision? I don’t read that as it assures what it say. To me, the padding assures the client can send this side of packet to the remote endpoint. Does this agree with what is written in section 8.1 on padding? and Section 14?
Yes, a client that does not pad to at least the minimum packet size for some version the server supports will not receive a Version Negotiation packet in response. The corresponding server text is in 5.2.2: This is both to prevent an attack vector from spoofed packets, and to reduce the risk that a non-QUIC packet will trigger Version Negotiation in response. There is a slight risk that the client might only support version of QUIC with smaller minima and the connection attempt will time out instead of discovering via VN that there are no mutually supported versions. However, if there is any overlap, compliance with this SHOULD enables the client to trigger the server's VN response. Yes, this aligns with the guidance in Section 8.1: and Section 14: However, those are in regards to a packet from this QUIC version, while the text you're asking about regards packets when the peer's QUIC version is unknown as of yet.
Not seeing any action here. As Mike says, the text describes sender requirements and explains why.
NAME
I agree with the logic in this thread, but this seems far too subtle/clever and others will be confused at this point. However, I read this as the remote checks that the minimum size is sufficient. That means not padding this breaks the protocol. Why doesn't that require a MUST for any version (sec 14). If it doesn't then this doesn't yet explain under what cases the present "SHOULD" can be violated.
Not padding breaks the protocol, so there's a MUST in Section 14.

That MUST does apply to all versions that the client supports; the client obviously can't know the details of versions it doesn't support, including any the server supports, so that's all it can reference. There's no minimum first-packet size in the invariants. The server SHOULD send Version Negotiation in response to a packet of unknown version but an appropriate size; if it doesn't, the client won't know what versions it supports, but it might choose not to do so every time. (Hence the "MAY limit" in the next sentence.) Is the thing that's missing for you a linkage between "SHOULD send" and "MAY limit"?
All of this makes sense, but it was the sentence in section 6 which I found unclear, which says: "Clients that support multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support." That made me ask what happens when they support a version and didn't pad to the min size required by that version?
Then they are violating the requirements of that version and won't get a response.
So let's say a hypothetical client supports versions with the following minimum packet sizes to open a connection: A: 1250 bytes B: 1200 bytes C: 1720 bytes The client is trying to open a connection with version B, so they MUST send at least 1200 bytes. However, if the server only supports A and C, this won't provoke a Version Negotiation packet and the connection attempt will time out. That's not incorrect, because the server doesn't support the attempted version, but it's suboptimal because there is overlap in the supported versions they could discover and use. The client SHOULD send at least 1720 bytes, because that guarantees the packet is large enough to trigger a Version Negotiation packet in the event there's any overlap in their supported version sets. It's only a SHOULD, not a MUST, because there might be legitimate reasons a client would opt not to send a 1720-byte packet, such as expecting a 1500-byte MTU on the network.

NAME
So if this confused me (a little), I am assuming it could confuse others, so one way to make this clear is add a sentence (albeit a little long) after the SHOULD in section 6 that says what happens and explicitly includes a forward ref to Section 14.1 i.e. AFTER THIS CURRENT TEXT: “The size of the first packet sent by a client will determine whether a server sends a Version Negotiation packet. Clients that support multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support. This ensures that the server responds if there is a mutually supported version.” ADD SOMETHING LIKE: "If a client sends an Initial packet (see section 14.1) less than the smallest allowed packet size for the version of QUIC supported at the server (e.g., when this size is not permitted by the local interface), the server would not reply with a Version Negotiation packet and the connection attempt will time out.
?
I think you know what to expect, to me the text just needs to explain what you expect can happen.
NAME does resolve this issue for you?
This text seems to answer my question - Since this in section 6, I'd have also preferred adding a forward reference to the later section 14.1 to get the details.Not sure if we really need this...