Thanks for putting this together, it is much needed!
- WikiApiary.com is a UX nightmare; a more practical list of popular extensions would be nice
- how do developers notify user communities of popular extensions about breaking changes? Phabricator might not be effective; some popular extensions might not have phab tags; some popular extensions are not in gerrit so easy to miss them when reviewing what will break. Should there be a concerted effort to improve that situation? Or some "things you need to do if you want to get deprecation warnings for your extension" guideline?
- MediaWiki core code and functionality MUST NOT trigger hard deprecation warnings... - maybe a better way to put that is MediaWiki core code that triggers hard deprecation warnings must not be reachable from non-deprecated core code using non-deprecated configuration settings. Triggering warnings in B/C APIs for extensions should be fine.
- what counts as PHP API? specifically,
- do we require depreciation for changes to old "everything is public" classes?
- do we require depreciation for changes to protected methods? (See T146440 for a recent example of such breakage.) We do not use private visibility that much so that would in effect turn every implementation detail into an API. Can we somehow tell apart classes that you are expected to subclass and ones where you are on your own?