> I don't think "remove de-recommended cypher" qualifies as a security fix for 3.3 or 3.4.  Certainly you're not permitted to add ChaCha20 to 3.3 or 3.4

I think that this is a bad stance to take here. The difference between a security feature and a security fix is incredibly hard to differentiate. For instance, with 3DES being de-recommended (and removed in future OpenSSLs) that leaves basically only AES-GCM and AES-CBC left as a secure cipher. This is a very precarious position to be in because all it takes is some reason that these constructions are less secure (it doesn't even have to be an attack on AES itself, could just be the way TLS uses it) and suddenly 3.3 and 3.4 don't have *any* secure ciphers. It is important from a security standpoint to have multiple secure ciphers available with different implementation details to protect against problems in one of them from causing widespread harm.

As far as removing 3DES, I think that we need to either remove it or we need to implement protections to prevent it from being used for too much data. 3DES isn't insecure so much as it's so old that you can only safely encrypt so much data with it with a single TLS key (Key == Connection roughly) before it becomes insecure. This is likely to hit automated tooling worse because it only affects things that hold long lived connections or re-use TLS session keys for a long period of time and a lot of tooling does just that for performance reasons.