Original text:
%%% Key Exchange Messages <del> The server_version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del>  Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake key_share (see key-share)  4.2. A number of TLS messages contain tag-length-value encoded extensions KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the <del> client, the client MUST verify that the selected NamedGroup matches one that the client sent in its supported_groups extension and MUST abort the handshake with an "illegal_parameter" alert otherwise. </del>  4.2.5.1.

Reviewer comments:
client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares.
NAME is this what you had in mind?
I did consider bogus binders, but dropping seems more sensible, and it seems like the only impact of the bogus binder would be that if the server didn't follow a consistent rule, then you would get a handshake failure at the server. It's not like it could pick them in any case.
(Agreed. This version feels way less weird.)
NAME comments welcome

Revised text:
%%% Key Exchange Messages  <ins> The version, cipher_suite, and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake key_share (see key-share) <ins> In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite.  This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.  A client which receives a cipher suite that was not offered MUST abort the handshake.  Servers MUST ensure that they negotiate the same cipher suite when receiving a conformant updated ClientHello (if the server selects the cipher suite as the first step in the negotiation, then this will happen automatically).  Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the  <ins> client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.5.1.