In the current SunJSSE implementation, the key share extension may use two entries, by going through the named groups and taking the most-preferred group from two categories (i.e. XDH and ECDHE) (See https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java#L248C1-L251C1).

This design mitigate a round of HelloRetryRequest if XDH is client preference but server does not support it. While this approach enhance server performance, it comes at the expense of client-side efficiency.

The design was created when XDH is not widely supported. Today, the widely support of X25519 should largely mitigate the concern that shaped the design. It may be time to produce only one key share entry in the ClientHello handshake massage, which is the default behavior of OpenSSL and browsers. Instead, the HelloRetryRequest mechanism could be used to negotiate supported key share algorithms. As will have a better balance between client and server performance: improved client performance without hurt server performance too much, even HelloRetryRequest is required for further negotiation.

Besides, the two key share entries policy also increases the TLS server implementation complexity. It is noticed that F5 load balancer may not work in some situation with two key share entries, but work with one.

Considering the TLS specification, and the widely use case in OpenSSL and browsers, the compatibility impact should be limited.