Thanks for bringing this up. And sorry to hear that many have had negative experiences with recent removals of deprecated code (though I had nothing to do with it).
The Pywikibot project is barely maintained; a small community of interested folks are pushing it forward, and most code gets merged without review. I don't think we can claim, in good conscience, that there are folks who still keep a full architectural view of all elements of this project (as is the case with MediaWiki and many other tools we use daily).
The point is: if the framework is too difficult to execute, it won't happen. So, although I like your proposed framework, I find it unrealistic to happen. It would assume someone is pulling data on Python version usage, and they would be involved in code review in such a way to ensure that code incompatible with legacy Python versions is not introduced too soon.
I would encourage us to come up with a framework that is easier to maintain, and mostly automatable. Maybe we should just use the "7 year" rule, make sure that we have a CI pipeline that tries to build Pywikibot for all Python version that are currently within that 7 years, and at the top of the CI pipelines' code we have a comment that educates the users who may decide to edit it when the 7 year period ends for each existing version of Python. This way, incompatible changes would just fail on CI, and the enforcement of rules is quite simple, and breaking them by accident (such as by someone unknowingly modifying the CI pipeline) is less likely. This was just an idea, and may not be the right way, but I hope it shows what I mean by simplifying matters.
Similarly, maybe we should find a way to create a CI pipeline that would check for "@deprecated" methods, and cross-checks it with a reference JSON file in which each deprecated function is listed along with its deprecation date. If someone tries to remove the function before that date + 3 months, the CI would fail. If someone tries to add "@deprecated" without updating the JSON file, the CI would fail. This way, we have one single source of truth about when things were marked as deprecated (the JSON file) and an easy mechanism to track when deprecated methods are getting removed. Again, just a raw idea.