[AnimalMuppet]

Maybe. But even with the old code base for reference, it's easy to not see that those weird lines right there are written the way they are to handle two different corner cases (and of course there's no helpful comments to explain it). This is especially true if you're rewriting from $MORE_OPAQUE_LANGUAGE to $CLEARER_LANGUAGE. There can be a lot of not obvious things going on in the opaque stuff, and you can drop things you need in the rewrite unless you are very careful.

As carlmr points out, tests can help a lot... if you've got tests for those corner cases. They can be new tests, created as part of the rewrite - if anyone remembers that they are needed, or if anyone can see the corner cases either in the problem space or in the code. (This argues for doing the rewrite while the original authors are still around, preferably with them as part of the rewrite team.)

[_bxg1]

Right. Put differently: any sufficiently long-lived codebase contains institutional knowledge. Knowledge that goes deeper than just the explicit interface boundaries that you're planning to re-implement. That doesn't mean rewrites are a bad idea, just a disruptive one. They'll introduce new fragility for a while before they start being a net gain. Code has to be broken-in, like a new pair of shoes.

[lmm]

> There can be a lot of not obvious things going on in the opaque stuff, and you can drop things you need in the rewrite unless you are very careful.

If the knowledge is so opaque as to be nonobvious from the code in front of you, then it's already an accident waiting to happen: someone making normal maintenance changes to that code (not a rewrite) would be equally likely to break those properties.