Yeah, it is a downside of this approach.
However, in full generality, the ABI-compatible entrypoint could also want to invoke a new API that takes an extra argument, or (as shown in your example here) that throws instead of rethrows, or that requires performing a simple arithmetic operation on an argument or converting it to a different type. The general workaround for all of the above is (as shown in your example) to write an additional @usableFromInline internal __whatever shim that can have an arbitrary prefix.
It's not clear to me a priori that the specific scenarios where there are multiple overloads differing in generic constraint which can't be disambiguated in today's Swift[*], say, so outnumber the scenarios where there are differences in number of parameters, throwing versus rethrowing, isolation, etc. that it should totally drive the design of this feature.
However, I am open to being convinced if, empirically, you're finding that this really is overwhelming scenario in which you'd use this feature.
[*] That we can't ergonomically disambiguate among certain overloads is something that we probably should work on, orthogonally. But I would consider it a solvable expressivity problem rather than a fact-of-life that we should yoke other designs to.