It would be very nice, once T107595: [RFC] Multi-Content Revisions is done, to provide all page-related meta-data in a single content (sub)slot.

Benefits

• This would allow most of the oddities of page-level changes to be shown more consistently and readily to users (for example, this diff page isn't very clear).
• It would also allow common double-edit actions to be replaced with a single, atomic, mutli-part edit for less work on the part of editors and more clarity (albeit needing a little more complexity in the tools) – for example, altering a page's protection status and adding/removing a protection template.
• This would enable a richer set of behavioural modifications to be done by MediaWiki itself rather than e.g. per-wiki JS gadgets – for example, special edit notices for members of a category (though this example will be fixed directly before this work is started).

A possible (not exhaustive) list of such meta-data:

• Title changes ('moves'); this would fix T10731: Make it easy to find log actions across a page move etc. and allow much more readily
• Title over-ride changes (DISPLAYTITLE; see question below)
• Protection changes
• Language link changes
• Category inclusion changes ([[Category:Foo:]]; note these are (?)intentionally relatively-positional to establish the page render order)
• Category sort title changes ({{DEFAULTSORT:…}})
• Redirect state changes (see question below)
• Other log-action changes which alter the state of the page (e.g. in FlaggedRevs, changing the 'accepted' revision pointer)
• Non-positional behavioural switch changes (e.g. addition/removal __NOTOC__, __NOEDITSECTION__, __INDEX__, __HIDDENCAT__)
• Page content model changes
• Others…

Some open questions:

• Would this be derived or primary?
  • If the former, what does that mean more generally? Is it more useful in that state?
  • If the latter, would we pull all the items out of the 'wikitext' slot but show them there on edit as a synthetic page to allow editing through that interface as well? Does that mean normalisation of existing wikitext sequencing? How beneficial vs. disruptive would this be for users? Are there any desired behaviours we currently have or in future would like to have that this would prevent?
• For things which are specific to the wikitext content model but are thought of more generally (e.g. Categories), is opening up this meta-data to those pages a good thing?
• For things which are currently specific to the wikitext content model but are actually about MediaWiki rather than wikitext – most obviously, redirect states and title over-rides – are these things we'd want to move out of the content model and into MediaWiki generally? See T45049: Automatically update content model when moving page.
• What'd we do about other meta-data like things that don't work in this model (e.g. positional behavioural switches like __TOC__, labelled-section transclusion and translation extension markers, etc.)?
• What'd we do about meta-data inherited through transclusions? (Category membership most obviously.)
• How can we make this nicely extensible (e.g. for Flagged Revisions to add additional data)