While working on https://gerrit.wikimedia.org/r/1338093 (related to T347123) we learned that all so called "double underscore magic words" are unconditionally stored as page props. This is an intended feature in many cases, e.g. for extensions like MediaWiki-extensions-Disambiguator. When __DISAMBIG__ is added to a page (either directly or via a template) that page gets marked as a disambiguation page via the disambiguation page prop.
The problem is that several page props appear to be entirely useless as a page prop and only waste space in the database, making it slower when querying other page props. One possible suggestion is a very short hard-coded list of these magic words that should not be stored as a page prop.
Core currently comes with the following "double underscore ids" in MagicWordFactory:
__EXPECTSHORTPAGE__, __EXPECTUNUSEDCATEGORY__, __EXPECTUNUSEDTEMPLATE__: All needed as page props in their corresponding special pages.__HIDDENCAT__: Essential to mark hidden categories as such.__INDEX__ and __NOINDEX__: Intended meta data about a page and used as such.__NEWSECTIONLINK__ and __NONEWSECTIONLINK__: Used by DiscussionTools and possibly others.__NOCONTENTCONVERT__ and __NOTITLECONVERT__: Used by Parsoid.
Remaining candidates:
- __TOC__: This is the strongest contender here as it doesn't really change anything about a page, only the position where the TOC is rendered, and only if that new position is different from the default. External users cannot learn anything about the page by querying this as a page prop, except that the magic word was somewhere on the page. Note the page prop is a bool and not the position of the toc, i.e. it cannot even be used for what it's intended to do.
- __FORCETOC__ and __NOTOC__: These change if the table of contents gets inserted into the page's HTML. I don't think Parsoid needs these as page props. Mostly irrelevant since Vector 2022 anyway.
- __NOEDITSECTION__: This changes how a page gets rendered, but doesn't serve much of a purpose any more after that's done. When and why would an external process need to know if a page contains edit section links or not? The same information can be found in the page's HTML just by searching for the edit section links via a CSS selector.
- __NOGALLERY__: As above.
- __STATICREDIRECT__: Not sure. Only used by a job, but that job seems to look directly into the wikitext and not the page prop.