Wholeheartedly agree with this! When I was working on Knot Resolver, I did a pretty successful rewrite of its I/O. The original one was a mess, but of course a

Wholeheartedly agree with this! When I was working on Knot Resolver, I did a pretty successful rewrite of its I/O. The original one was a mess, but of course a lot of it did make sense in the grand scheme of things - it's only that the requirements had changed with time (mostly caused by the addition of DNS-over-TLS, DNS-over-HTTPS, and, in the future, DNS-over-QUIC), so various adaptations needed to be made to the original code. But, as the changes were largely incremental, it resulted in something that was pretty hard to reason about. So I literally tore out the thing that I considered the most "wrong" about it, but sort of kept it at the side; then I started reimplementing it by mixing new code better suited for the current (and hopefully near future) requirements with the old copy-pasted code. Spinning a bit off-topic, but perhaps sort of relevant to anyone planning to do something like this. The biggest gratification for that effort did not come immediately. Rather, the result was initially pretty underwhelming. Yes, the code seemed to be more readable, robust, and extensible, but since there was no immediate need to touch that area for some time, I started questioning whether it was actually worth it. But then, about a year and a half later, some new requirements arised, which proved that the effort was actually worthwhile. And we even had a direct comparison, because a security fix was needed for both the old, still-supported, version, and the new one, so it was nice to see the difference between what it took to fix the old one and the new one.