Original text:
A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is <del> requesting a HelloRetryRequest.  The ordering of values here SHOULD match that of the ordering of offered support in the "supported_groups" extension. </del>  The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.

Reviewer comments:
The text already says that both supportedgroups and keyshares are in order of "client preference". Supposing "client preference" is a well-defined notion, we are already requiring the order match. The SHOULD was also unclear on whether the list may be a general subsequence. Clarify that this is allowed. This may be useful if, say, we define some very large NamedGroup (post-quantum?) in the future that is still preferable over the existing options. Clients would likely wish to NOT offer it initially because it would be a waste of bandwidth for the vast majority of servers which don't support it. (Not to mention intolerance problems.) In that scenario, a client would likely not predict a keyshare by default and instead use some kind of server info cache (either caching what the server chose or using the full server supportedgroups list). But that client would still wish to advertise the new group first.
This is what I get for uploading PR immediately before trying to enforce it instead of immediately afterwards... :-) On the plus side, yay for tests! The list in the extension is supposed to be "in descending order of client preference". However, this isn't true for the second ClientHello because the new KeyShareEntry is always appended. It's only a SHOULD-level requirement with reverted, but the spec text is still off, and it is a little bit odd for stateless HRR implementations. (Though if the stateless implementation remembers in the cookie that it already committed to a group, it's probably still fine?)
Just put an "except for the last , in the case where an additional is requested with a HelloRetryRequest" or something on the sentence.
Sounds reasonable. Another option is we say isn't ordered at all. I dunno, maybe you have to keep them sorted or something. There already is a ordering. We're pretty ambiguous right now about whether is a secondary preference list or merely a prediction set. (I think it's best to make it a prediction set and avoid the complex semantics.)
Although keeping them sorted would be a huge pain, even if it is easier to enforce. That's probably not a good idea.
Well, if we wanted the HRR case to jive nicely with sorting, we could mandate reverse priority order; the appended would be top priority. This would work nicely, but could be considered unnecessary if sorting is any burden. I don't remember if this was specifically why I put a SHOULD here, but mandating an absolute requirement here could just be more trouble than it's worth. The worry with not having any requirement is that a pair of bad implementations could use the keyshare priority instead of supportedgroups and mess things up, however I'm not so sure it's that big of a risk. I think a SHOULD with NAME exception is fine.
NAME proposal on-list to replace the key_share after an HRR, rather than append to it, would fix this rather easily. Much better than fiddling with the language or ordering.

Revised text:
A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is  <ins> requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. </ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.