Original text:
a client might offer shares for several elliptic curves or multiple integer DH groups.  The key_exchange values for each KeyShareEntry MUST by generated independently.  Clients MUST NOT offer multiple <del> KeyShareEntry values for the same parameters.  Clients and servers MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare.  Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegal_parameter" alert. </del>  If the server selects an (EC)DHE cipher suite and no mutually supported group is available between the two endpoints' KeyShare

Reviewer comments:
For issue . This relaxes the requirement to check for and error on lack of inclusion in both extensions and focuses the explicit error requirement on the case of multiple keys for the same group.
Clients MUST NOT offer multiple KeyShareEntry values for the same parameters. Clients and servers MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supportedgroups" extension. Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare. Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegalparameter" alert. It's a pain in the ass to check for KeyShareEntry values that are not in the NamedGroups and NSS doesn't presently do it. I think the requirement should be relaxed to just be that you don't select one of them.
NAME I think you wrote this text. Objections?
Relaxing this a bit should be fine. Letting redundant keys slide sounds a bit risky for interop, though. PR with new text submitted.
The "MUST" for what error to throw could be reduced to a "SHOULD", if you'd like to make this even less strict. Not likely to come up that often, though, and I don't see it being more than an interop & waste issue (at least at the moment).
I think that MUST NOT send and MAY generate a fatal error is the right balance here. As an implementation, it's annoying to do this sort of validation because you have to cross validate two extensions, and most of the code for extensions is in the extension handler. Note that even the check for duplicate groups is not something that NSS does. (Did you want to close this now?)

Revised text:
a client might offer shares for several elliptic curves or multiple integer DH groups.  The key_exchange values for each KeyShareEntry MUST by generated independently.  Clients MUST NOT offer multiple  <ins> KeyShareEntry values for the same group and servers recieving multiple KeyShareEntry values for the same group MUST abort the connection with a fatal "illegal_parameter" alert.  Clients and servers MUST NOT offer or accept any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare. </ins> If the server selects an (EC)DHE cipher suite and no mutually supported group is available between the two endpoints' KeyShare