Change:
Every other use of Diffie-Hellman preserves leading zeros. See PKCS section , RFC 2631 section 2.1.2, and SP 800-56A section C.1. I assume X9.42 says something similar to RFC 2631, but I do not have a copy of it. This discrepancy has caused sporadic interoperability issues in TLS 1.2's DHE construction, so clearly it's confusing. Moreover, having variable-length secrets is generally dubious. It exposes an unnecessary side channel. Since TLS 1.2's server-fiat DHE and TLS 1.3's negotiated DHE are already very different animals (1.3 DHE is more like 1.2 ECDHE than anything else), change it to the more reasonable scheme going forward. This is not compatible with 1.2 and does risk a different set of sporadic interop issues if implementations do not realize this changed, but we already have those with 1.2 implementations today.
Edited: Karthik pointed out to me that only the inner length, which was clearly redundant, was dropped in Draft 13. So there is no need for a fix, but there is an opportunity for some savings by changing the encoding of shares. PR changed the text to require padding DH shares to the length of the group, making communicating the length redundant. We could save 2 bytes per share and some processing for parsing and checking the length by specifying as a fixed-length vector with a length dependent on the field. This could also be done for ECDH shares since their length is determined by the curve (because any given curve must specify a single point format). I don't know exactly what is the proper syntax to use, but what I mean is something like this:
The problem with this is that a new named group will have an indeterminate length. The current design is fine.
Concur with MT's analysis.
A new named group will have an indeterminate but fixed length, so the 2-byte length will still be redundant. The struct can be extended as needed for new named groups. The problem I see with redundancy is that implementations will have to check that the length field is consistent with the expected length determined by the group. Implementations will be tempted to omit parsing the length and doing this check. I haven't found any security concern with ignoring the 2-byte length, but being free to choose 2 arbitrary bytes sounds like a bad design. In brief, what I'm suggesting is to either make a MUST for implementations to check that the length bytes encode the expected length
This proposal doesn't work. An old implementation that encounters an unknown new group needs to know the length of data it needs to skip.
Fair enough, you're right. Then, would it be ok for an implementation that encounters a share from a known group and uses it to ignore the 2-byte length?
Failing to check values leads to bugs. c.f. Heartbleed for an extreme example. Implementations that encounter a 37 octet P-256 share should probably reject that message, but they are not obligated to do so if they aren't using the share.
We need to decide whether renegotiation is a part of the protocol. If not, then suitable replacements for the following features may be needed (thanks Nico for the list): rekeying authenticate the client when needed rather than always at handshake time privacy protection for the client's identity privacy protection for the server's identity privacy protection for the server identity desired by the client I'll raise separate issues for tracking these.

Discussion:
7.3.1. A conventional Diffie-Hellman computation is performed.  The <del> negotiated key (Z) is used as the shared secret, and is used in the key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF. </del> <ins> negotiated key (Z) is converted to byte string by encoding in big- endian, padded with zeros up to the size of the prime.  This byte string is used as the shared secret, and is used in the key schedule as specified above. Note that this construction differs from previous versions of TLS which remove leading zeros. </ins> 7.3.2.