I 100% buy that OpenSSL hasn't dug itself out of the hole it was in back in 2012. But building a new TLS library puts you in the same hole with respect to exhaustive unit test coverage, right? You're better off starting from a place where you already have a fairly extensive (if incomplete) unit test infrastructure than one where you're starting from scratch.
This is a weakly held opinion. I'm mostly motivated by the knee-jerk response OpenSSL gets on threads like these; I think those responses are based on a reputation that doesn't capture the level of work that has gone into the project in the years since 2012. That doesn't mean it's the apogee of what we can do with a TLS library.
I agree that it is in much better shape today and any competing project starting from scratch would be at a disadvantage with respect to the size of their test suite. However, I also like the BoringSSL approach of forking the project and deleting all the dumb features that nobody needs. They deleted the option flag involved in this advisory, years ago. By deleting it they avoided having to add tests for it.
Ultimately I agree with you about what the right approach is, but the route there is convoluted. BoringSSL is able to be simpler by defining pretty tight criteria for what it cares about and everything else either doesn't work or isn't guaranteed to exist at all.
I happen to think the safe way forward is to agree that OK then, we can't do all these other weird things, too bad. But this is an extremely unpopular position because lots of people have at least one weird thing they very much want to do.
This is a weakly held opinion. I'm mostly motivated by the knee-jerk response OpenSSL gets on threads like these; I think those responses are based on a reputation that doesn't capture the level of work that has gone into the project in the years since 2012. That doesn't mean it's the apogee of what we can do with a TLS library.