They said in the article they couldn't fix the stuff because it would break other stuff. That causes new stuff to be broken, though, since what the docs or code says isn't true. So, if not fixing old stuff, then I see two options:
1. Leave it broken with specs or docs modified to tell you what it actually does. Then, software that doesn't need it can do input validation or use it more carefully to avoid the failure mode. If they use it at all.
2. Fork each release that ensures backward compatibility into a backward compatible one and one that fixes old bugs. So, new projects or those willing to update can use the latter with the least-buggy version. Projects unwilling to update can use the buggier one. Users then get to choose either which one to use or, if mixed workload, they can isolate the buggy stuff in a VM. High-assurance security recommends that for Linux in general but this model gives extra motivation. ;)