This rule aims to keep the source code as maintainable as possible by reducing the amount of overloads.

If the signatures themselves are mergeable, then it seems like it aligns with the rule to merge them, regardless of parameter names.

I wouldn't hugely want to rely upon parameter names in this rule.

different parameter name is a good indication that the overloads are not compatible

In some cases, maybe. In others - no.

declare const foo: {
  (argument: string);
  (argment: boolean);
  (arg: number);
}

Are all 3 signatures here unifiable or not? Probably not if you're looking at naming. Could probably implement a heuristic like the Levenshtein distance to check for this. It's a lot of code to maintain for an rarer case / requirement though.

If the signatures themselves are mergeable, then it seems like it aligns with the rule to merge them, regardless of parameter names.

The overloads I showed are completely separate though, functionality-wise, and in the actual code, they have separate doc comments too.

Here's the actual code: https://github.com/sindresorhus/find-up/blob/e852e9cfd020844fac0ea2ff073c378cc302db4d/index.d.ts#L84-L135

In some cases, maybe. In others - no.

That example is not realistic. A realistic example would be something like:

declare const foo: {
  (argument: string);
  (arguments: string[]);
}

Could probably implement a heuristic like the Levenshtein distance to check for this.

That's too far, I think. But a simple pluralization check could make sense.

Happy to accept a PR for a default off option which tells the rule to ignore signatures if the param names are different.