People that wrote it are probably as smart as you are – maybe even smarter, since they (sometimes) wrote code that make a product that sells pretty well over a couple of decades.

So here we go (and I have just two points):

Don't change code only because you assume that it has faults.

You have to prove that, first (using debugger / profiler). We are not in a beauty contest, here.

Don't change interfaces.

Changing the behavior of a Class / Method is no problem, if that Class / Method is used in a precisely defined, local context. Changing interfaces of Classes / Methods that are wildly used in a complex application are a no-go even in the context of a quasi-automated Refactoring.

Don't do that. Use the Compiler to unveil your errors: rename a Class / Method that needs a new behavior, and let the Compiler's errors lead your way thru.

Sidenote:

If some code doesn't do what you assumes it should do, that doesn't mean someone else shares your assumptions (and your reasons for changing it's behavior).

She might rely on some assumptions that might seem stupid to you, but she might rely on them for good reasons (even if those reasons are founded on a reality that goes decades back).