Original text:
determined by the specified group and its corresponding definition. <del> The "extension_data" field of this extension contains a "KeyShare" value: </del>  <del> %%% Key Exchange Messages </del>  A list of offered KeyShareEntry values in descending order of <del> client preference.  This vector MAY be empty if the client is 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.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </del>  <del> A single KeyShareEntry value that is in the same group as one of the client's shares. </del>  Clients can offer an arbitrary number of KeyShareEntry values, each representing a single set of key exchange parameters.  For instance, these rules and abort the handshake with an "illegal_parameter" alert if one is violated.  Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest.  If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello.  This value MUST be in the same group as the KeyShareEntry value offered by the client that the TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to <del> "new_session_ticket" and to add the "hello_retry_request", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </del>  This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.

Reviewer comments:
I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).

Revised text:
determined by the specified group and its corresponding definition.  <ins> In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value: </ins>  <ins> %%% Key Exchange Messages struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; </ins> A list of offered KeyShareEntry values in descending order of  <ins> client preference. </ins>  <ins> This vector MAY be empty if the client is 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.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. </ins> Clients can offer an arbitrary number of KeyShareEntry values, each representing a single set of key exchange parameters.  For instance, these rules and abort the handshake with an "illegal_parameter" alert if one is violated. <ins> In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value: %%% Key Exchange Messages struct { NamedGroup selected_group; } KeyShareHelloRetryRequest; The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins> Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest. <ins> In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value: %%% Key Exchange Messages struct { KeyShareEntry server_share; } KeyShareServerHello; A single KeyShareEntry value that is in the same group as one of the client's shares. </ins> If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello.  This value MUST be in the same group as the KeyShareEntry value offered by the client that the TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to  <ins> "new_session_ticket" and to add the "hello_retry_request_RESERVED", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.