It's a million times easier than figuring out if those minor differences in duplicate code are accidental or on purpose.

As bad as a flag-laden method might be, you know the intent of all callers.

It doesn't have to be that way, it's just because our existing language facilities don't have support for what we need them to do:

"Names are regularly repurposed to point to new definitions, even when the old definitions are still perfectly valid. For instance, a library author might make a function a bit more generic by adding an extra parameter, or decide to switch the parameter order. That's fine, but the old definition was not wrong, so should users be forced to upgrade? No.

Repurposing names is fine; it's hard to come up with good names for definitions, so using an old name for a related new definition often makes sense. The trouble is that existing tooling doesn't distinguish between repurposing a name and upgrading a definition. Unison changes that..." https://www.unisonweb.org/2020/04/10/reducing-churn/#incompa...

It's very easy with proper tooling.

Outside of publishing a public API almost any modern language and enviroment should make this easy.

I find it much easier to find the call sites for a function than to find code that’s duplicating or a variant of the code I just fixed a bug in so we can figure out if the same bug is latent in the duplicates too.

Not in any modern language or IDE. Not to mention that would indicate a hole in the test suite