My point is that it isn’t obvious. You may think it’s obvious based on your personal experience, but that’s an argument that has to be made. You cannot assume that we also already agree with you.
But let’s suppose that soft deprecation is all that happens. In other words, there is no date at which the existing API is to be removed. All you’re doing is putting a note in the docs saying “use this alias instead”. Okay. So, suppose you’re developing some software. You have a choice: use re.match(), which will work on all existing versions of Python and all planned future versions as well, or use re.search() with an anchored regex, which will also work on all existing and all planned versions, but will be less efficient. Which do you choose? Does the deprecation make any difference here?
You are, of course, free to replace all uses of re.match in your own code with re.search. That’s fine. Nothing wrong with it. But the deprecation won’t actually add anything to that argument, unless you can show that there is real benefit to be gained here.
Liike I said, you’re going to need to do some research here. “I almost never see” isn’t enough of an argument. How many cases do you find of this on GitHub (or some other large corpus of code)? How many major projects have this happening?
No, the time to get those statistics is now. You won’t get traction for any further steps otherwise. And “somebody may be inclined to”? Are you asking someone else to do the work for you? If so, go change this in your own codebase only, and don’t ask for deprecation. If you want to push for a language change, you have to be prepared to do your own research.