Absent a high performing systems language that still offers some safety guarantees, the right call should be to use whatever the second best is. It could be a higher level language with runtime overhead, sandboxing, formal verification etc. In some cases constraints won’t allow this, and obviously replacing even parts of infrastructure code is never easy. Nor should the perfect be the enemy of the good - adding better testing doesn’t sound like a bad idea even for a piece of code being sunset. What I’m objecting against is the (apparent, or my perceived!) idea that “if only the fuzzing was good enough, this code would be acceptable for use forever.