Adding VisualEditor as I think it was requested we add it even for non-visual-editor-editing tasks, IIRC.

@Jdlrobson Do you have any thoughts around why we're not respecting this? Would it be hard to do?

Is this not the point of it being "probably" editable? It's not necessarily telling you for sure whether it is or not, for performance reasons.

Is this not the point of it being "probably" editable? It's not necessarily telling you for sure whether it is or not, for performance reasons.

That's fair :)
I'm not sure how viable it is to check the title at the start of the workflow but it does seem like something that can be checked up front.

This isn't related to VE or MobileFrontend. The same applies to Vector and desktop for example.

Abuse prevention controls are generally considered expensive and are likely not going to be run proactively prior to attempting to submit a form. Both for performance reasons, but also due to the design of the technical interfaces behind it (which react to an edit submission and all the context related to that, not merely a title).

There are likely also good reasons around trust and safety, and voice and tone that would likely prevent us from wanting to render such attempts in ways that acknowledges anything about them. There are ways this can be abused and backfire. There is also a general expectation that page headers are consistent between associated pages and actions (view/history/edit, subject page and talk page, special pages such as Move and Undelete), and thus this infromation would have to be computed in that context as well, and then propagate to skins through any relevant caches.

From a user experience perspective I'd say this is a non-issue. Page protection is something we expect "good" users to encounter, so we want to help them and be informative. Abuse prevention controls aren't meant to affect good-faith behaviour so the example in the task involving the word "moron" is not something I think we need to be concerned about.

What does seem more of a concern is the use of TitleBlacklist to essentially deny editing of certain pages to newer users. My guess is that this is not a use case that the technology was designed for, and when it ends up applied in this way without consulting engineers, it is not going to work as expected as we find here. Perhaps a feature request coud be filed to allow /Editnotice pages to be protected in a similar manner that /common.js is protected through a user right.