This isn't really the situation. The old code does not have to handle any new elements. It just has to compare (1,3) to (1,2) and send (1,2) the same as before. It has to look in an explicit list of optional items, and skip over all the optional items it does not know, and include only the ones it does know. This is all trivial and many implementations get it right. You don't need fuzzing for this part. Any remotely sane code would work just as well for (1,4) or (2,0).

There were probably some problems with odd dumb custom-coded gadgets. But mostly, the problem is with "value-add extra-security" boxes in the middle that don't _do_ the protocol at all. They are not a TLS client or a TLS server. They are a product which promises to spy on the traffic and "stop the hackers". They really can't do anything useful. They just see that the handshake packet had (1,3) instead of the familiar (1,2) and drop it. For good measure, they also block packets between those endpoints for 24 hours (so fallback retries don't work). Also they didn't add (1,3) to their recognition system a couple years ago when tls1.3 was in the works, because anyone buying or selling these things is just not very on top of things. So, all the middleboxes which are popular enough to matter, need to be tricked with obfuscation, so they're _really_ not doing anything.