Deprecated means in its general sense to disapprove something or to give it little value. In the software context, it means to discourage the use of a feature.
In the Java Community, for example, deprecated has indeed frequently the meaning of a future removal. But this is not the only reason:
the API has been superseded by another API,
the API is obsolete,
the API is experimental and is subject to incompatible changes,
According to this interpretation, incompatible changes could also be covered by the term deprecation. So there is not really a need for a new term.
But regardless of how you call this change in the API, this is not a good practice, unless you're still in preprelease (release 0 in the semver API versionning scheme):
- Keeping the same function name with a different interface forces the users of the API to do the change timely with your new API publication. They have no way to adapt their code in advance, but as soon as you release the new API they have to quickly update every call. This is very inflexible ! Your users may have to block a release cycle for your adaptations.
- Keeping the old function with the old signature, but deprecated, and introduce the new function with the new signature under a new name, allows you to let both versions coexist temporarily. The users can then migrate their code to the new API at their own pace over several of their releases. This is much more user friendly (and professional).
- Of course, if the language supports overloading and accepts the same name with both signatures and without ambiguity, you may let both deprecated and new function coexist under the same name.