Right, this is the one issue with protocol conformances and subclasses that would cause problems here.
But: it's already a problem when a user (legitimately) wants to implement a protocol requirement but prefers alternative internal parameter names than those given by the protocol. For instance, in the Swift standard library, several of the SIMD implementations of binary operators required by protocols were changed to name the operands a and b, instead of lhs and rhs, to standardize with other binary operator implementations that aren't protocol requirements. Any inherited documentation inherited from a protocol is now broken.
This is a tooling bug, and it's the tail wagging the dog to try to "solve" this by contorting the design of a language feature.
This wouldn't address the problem regarding protocol conformances by itself, since _parameterName is still different from parameterName, just as _ is. We need to teach the tooling to understand that implementations can inherit protocol documentation and match up the arguments by position to behave correctly to support _, and if it does that, then the _parameterName workaround wouldn't be necessary.
I see your point about telling the user something about what the _ is, but I think that can be accomplished in the tooling itself by, for example, numbering unnamed parameters in the generated documentation rather than privileging "magic" underscores in this one place. We already number unnamed parameters in closures, so the same syntax in documentation could be intuitive here.
Swift, which started off eschewing the punctuation-heavy syntax of Objective-C as a major attraction to users, has already acquired or expanded the use of a bunch of sigils like \ and $ and @ that prefix names. Used judiciously, sigils can be powerful, but I don't think this problem rises to one that could justify a solution that endows yet another sigil with additional special meaning instead of relying on existing syntax.
This empiric evidence is so key to motivating this: in the draft implementation, the core team indicated that adding diagnostics for stylistic purposes isn't desirable: it is extremely useful to show (as the bug that motivated this thread and your examples do) that there are actual, real-world bugs that are mitigated by this diagnostic. That is very strong evidence to favor making a change.
I did not consider it to be a problem with the pitch. I could find no problems. The bug is just something I stumbled on while toying with it, and which should presumably be fixed regardless of the pitch.