This is also an essential enterprise feature - the WMF will need to implement this anyway if they decide to offer commercial MediaWiki support (see https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Working_Groups/Revenue_Streams/Recommendations/4).

Other use cases include long term abuse documentation, other stuff we use private wikis for (Checkuser, arbcoms) and stuff that should be hidden but is currently public (TitleBlacklist).

CC subscribers of T14251: Read restriction support

Given the need to restrict transclusion as a work-around, and to avoid burdening the caching, I would suggest that read-protected pages not be transcludable at all, rather than only being shown on inclusion if the user has the relevant rights. A first implementation may only allow the protection to be for an entire namespace (intended for extensions adding namespaces), and require that protected namespaces also be part of wgNonincludableNamespaces (per DefaultSettings comment, "Among other things, this may be useful to enforce read-restrictions which may otherwise be bypassed by using the template mechanism.") since as far as I know there isn't currently a way to exclude pages on a page-by-page basis from transclusion.

Adding wishlist per T156788#2997881

If I read the task title correctly, this task is about fully implementing read/view restrictions in "mediawiki core". So tagging Platform Engineering for review.

We think this sounds interesting, but it's not functionality that's on our (CPT's) roadmap at this point. We're putting this in our icebox, but if someone picks up the project and starts moving it forward, we'll start actively tracking it and can provide friendly cheerleading. This level of functionality requires an RFC.

In T230668#5882268, @eprodromou wrote:

We think this sounds interesting, but it's not functionality that's on our (CPT's) roadmap at this point. We're putting this in our icebox, but if someone picks up the project and starts moving it forward, we'll start actively tracking it and can provide friendly cheerleading. This level of functionality requires an RFC.

RfC created at T249380: RfC: Per namespace view restrictions

Another usecase is T63302: [QuestyCaptcha] Store questions and answers in an automatically encrypted page, whose plaintext is viewable only by sysops.

In T230668#6226967, @Aklapper wrote:

@Akuckartz: Could you please reply, instead of reverting changes? Thank you. :)

Sorry! No, I currently do not intend to work on it. When will it be triaged?

@Akuckartz: If your question is about the "Priority" field, then maybe whenever someone [plans to] work on this task. I don't see anything here to "triage".