Change:
There are other uses of "in order" that the editors may like to address to avoid potential misunderstanding: /An adversarial receiver might intentionally not acknowledge packets containing stream data in order to force the sender to store the unacknowledged stream data for retransmission./ would be clearer as /An adversarial receiver might intentionally not acknowledge packets containing stream data so that it forces the sender to store the unacknowledged stream data for retransmission./
There are other uses of "in order" that the editors may like to address to avoid potential misunderstanding: This also is potentially misread: /An adversarial sender might intentionally send fragments of stream data in order to cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure./ and could be /An adversarial sender might intentionally send fragments of stream data that cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure./
There are other uses of "in order" that the editors may like to address to avoid potential misunderstanding: /Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet./ ... seem like /Servers SHOULD be able to read longer connection IDs from other QUIC versions to properly form a version negotiation packet./
"in order to" seems like a well-known construction, so I'm not concerned about its existence. Your rewording loses the implication of "SHOULD... because you'll need to...." Though I see your point that this sentence could be parsed as "reading in order" being the thing servers SHOULD be able to do. Perhaps "In order to properly form X, servers SHOULD Y"?
Also, this seems to be the same sentence as ?
That works for me - starting with the construction seems clear. Gorry
The new PR appears to have all the in orders in good order then!
There are other uses of "in order" that the editors may like to address to avoid potential misunderstanding: /Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet./ ... this might be misread as an ordering requirement, but I think is intend to be: /Servers SHOULD be able to read longer connection IDs from other QUIC versions to properly form a version negotiation packet./
FYI, it's more readable to quote with , e.g., this might be misread as an ordering requirement, but I think is intend to be:
All looks clear to me.

Discussion:
Destination Connection ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20.  Endpoints that receive a version 1 long <del> header with a value larger than 20 MUST drop the packet.  Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. </del> <ins> header with a value larger than 20 MUST drop the packet.  In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions. </ins> The Destination Connection ID field follows the Destination Connection ID Length field, which indicates the length of this

This length is encoded as a 8-bit unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20 bytes.  Endpoints that receive a version 1 long header with a value larger than 20 MUST <del> drop the packet.  Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. </del> <ins> drop the packet.  In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions. </ins> The Source Connection ID field follows the Source Connection ID Length field, which indicates the length of this field.

21.5. An adversarial sender might intentionally send fragments of stream <del> data in order to cause disproportionate receive buffer memory </del> <ins> data in an attempt to cause disproportionate receive buffer memory </ins> commitment and/or creation of a large and inefficient data structure. An adversarial receiver might intentionally not acknowledge packets <del> containing stream data in order to force the sender to store the </del> <ins> containing stream data in an attempt to force the sender to store the </ins> unacknowledged stream data for retransmission. The attack on receivers is mitigated if flow control windows