Well, my counterproposal: deprecate them (!), but keep them working for now. Only remove those that actually are a burden to maintain, or block development.
It’ll save work for you, and (more importantly) for users of the API.
See also @thomas post here: C API: What should the leading underscore (`_Py`) mean? - #11 by thomas
You cannot identify all affected C extensions. A PyPI search is missing Conda packages, Linux distros, private codebases, &c. A search for popular packages is miscounting people who are responsible enough to set up a PyPI mirror.
Not all of the maintainers are interested in fixing their legacy API, or reaching out to you on the issue tracker, right now this year.
Also, in my experience it’s not easy to convince you to revert a removal.
It’s good to convert useful private API to public/unstable. But it can be done without massive breakage of legacy code.
IMO, pythoncapi-compat is great for providing new API for old Python versions. But if we want to provide old API for new Python versions, why not do that in CPython itself? After all, pythoncapi-compat seems to be for functions that can be implemented easily; keeping a deprecated function in CPython instead doesn’t sound like a big burden.