The Page interface was introduced in [[https://www.mediawiki.org/wiki/Special:Code/MediaWiki/91123|r91123]] (June 2011) as a temporary migration step on the way to splitting WikiPage and Article. Also as a temporary migration measure, all WikiPage public methods were duplicated into Article, proxying to WikiPage. `Article::__get()` and `Article::__set()` were added, to provide temporary access to WikiPage public member variables via Article. All of these temporary migration hacks still remain, 8 years later.
I believe that fixing this is feasible for a talented contractor.
Work plan:
[x] Hard-deprecate all methods of Article that say they are a "Call to WikiPage function for backwards compatibility", except for getActionOverrides().
[x] Hard-deprecate the following other Article methods: `__get`, `__set`, doDeleteArticle(), doUpdateRestrictions(), updateRestrictions(), doRollback(), commitRollback().
[x] Rectify any callers of the above methods in core and WMF-deployed extensions -
[x] Make Action::factory() and Action::__construct() take an Article as a parameter instead of a Page. [[https://codesearch.wmflabs.org/search/?q=extends%20Action&i=nope&files=&repos=|Codesearch]] suggests that only Flow will be broken by this, requiring a simultaneous update.
[x] Add Action::getWikiPage() and Action::getArticle(). Soft-deprecate direct access to Action::$page in favour of these new accessors and fix such access in core.
[x] Soft-deprecate the Page interface.
[] **DELAYED TILL 1.36** Remove all type hints of the Page interface from core, replacing them with Article or WikiPage as appropriate. According to PHPStorm, there are only 7, all apparently quite feasible. - we have decided to delay this till 1.36, since then we will be able to replace it properly for either Article or WikiPage, and not Article|WikiPage
[] Similarly, in WMF-deployed extensions, rectify direct access to Action::$page and type hints of the Page interface. - T248492