T149344 could be related?

@Cenarium Another question. For a heavily transcluded page, is it the unreviewed edit that's meant to be the "heavy" action that adds to the job queue, or the act of accepting (unaccepting) the edit (meant to make the change go live) that adds to the job queue?

@Cenarium the results I'm getting (testing with a non-reviewer account in tandem). In all cases, page B has unreviewed edits. Suppose the unreviewed edit on page B is in section "Foo".

1. Transclude B onto non-PC-enabled page A: unreviewed changes of B are seen when viewing A logged out.
2. Transclude B onto PC-enabled page A generating an unreviewed change for A, then later this change is reviewed: unreviewed changes of B are seen when viewing A logged out.
3. Substitute B onto non-PC-enabled page A: contents of what's being substituted were from the latest unreviewed version of B, and the public sees this.
4. Substitute B onto PC-enabled page A generating an unreviewed change for A, then later this change is reviewed: contents of what's being substituted were from the latest unreviewed version of B, and the public sees this.
5. Use #section-h to transclude section B onto page A. The contents of the section that's transcluded is from the latest revision of B. If A has no unreviewed edits, these changes are live.

There are articles that transclude sections of other articles (#section-h and <onlyinclude>, etc, see https://en.wikipedia.org/wiki/The_Fast_and_the_Furious). Pretty sure the sections that get transcluded will be the latest revision despite possible unreviewed changes, which seems to be a problem.

@Cenarium At enwiki as far as I know, the template namespace doesn't seem to allow turning flagged protection on. As for transclusion of unreviewed pages, the issue seems known by VPT, but since stronger flavors of flagged protection don't officially have consensus yet, this hasn't been a big problem.

@Cenarium The patch does not give a short time frame in which non-admins can patrol articles, i.e. I think it makes sense to introduce the patroller group and allow some time for sysops to populate it while autoconfirmed still has the patrol flag. A second patch then removes the flag from autoconfirmed once patrollers are set.

As far as I know, bureaucrats don't have the patrol flag

Updated original to archive link.
If the destination page was not "deleted" but moved with suppressredirect, would the deletion log still show (as it does in other circumstances)? As for the additional warnings, should a create prot level warning at semi (and extendedconfirmed for enwiki) show? Also assuming that bots and automated processes would need to be be unaffected by the additional warnings.

Great to hear!

Any updates or suggestions by any chance? Interested if this may be merged soon @Legoktm

Began working on this, expecting to have a changelist for review shortly.

@Aklapper thanks for the link and your feedback. Haven't had as much experience, and any upsetting of workflow was unintended. I've restored lowest priority in the meantime. (I'll consider elaborating the scenario on a mailing list)

FYI not reproducing this issue on my own laptop, Win10, Firefox 49.0.1, vector skin

I attempted to clarify that this is an issue when performing a move operation on a subject page that, given the option to move-subpages, talk subpages are not visible to the end user. This is critical for editors handling page moves, especially if the subject namespace does not support subpages, and the talk namespace does, and the editor cannot see the pages meant to be the talk pages of other distinct legitimate articles (i.e. MediaWiki thinks they are talk "subpages" when they are actually standalone).

See additional follow-up at https://en.wikipedia.org/w/index.php?oldid=742912477#Technical_implementation
Appears that the updated suggestion is invalid - not possible to know the destination subject/talk namespace pairs in advance, and not able to know of both destination namespaces support subpages.

Updated title, let the option be default only if both the subject and talk namespaces relevant to the move occurring support subpages. See https://en.wikipedia.org/w/index.php?oldid=742847522#Technical_implementation

@Legoktm I'm a bit new at this, but as the bug filer, solution is fine by me for now. (wonder if tech ambassadors wanted to add anything) Makes sense to continue to track this

In T145174#2634780, @Bawolff wrote:

I guess we would see if the current content model can be converted (losslessly) to the required one. If so do that, if not refuse to move the page.

Makes sense. I think this would solve the other (possible?) issue that Modules (Scribunto) can be moved to the Wikipedia space and stay Scribunto. After this, I believe that module moves would be converted to wikitext.

@Bawolff @Legoktm Given the scenarios I tried above, I think it's very difficult to ensure that titles have a default contentmodel. Page moves (like CSS to JS, or even default wikitext to a css subpage) is a workaround to the proposed function.

What happens if User:Example/common.css doesn't exist, and User:Example moves User:Example/common (not a CSS page, not in CSS contentmodel) to User:Example/common.css? I'm able to move a sandbox to a new css page: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Andy_M._Wang/sandbox&action=history

Comment: if it's decided that edit-previous-revision cross-contentmodel is to be supported, then non-autoconfirmed users (or whatever the scope of editcontentmodel is) should not be able to edit a revision with a different contentmodel because they don't have the permission.

@MZMcBride Similar issue in that undo doesn't work when there's an intermediate edit... but I'd say that in terms of usability, it's not as disruptive, and not being able to undo page moves is well-known. Users are given a "Move" option in the tabs at the top that takes users directly to Special:MovePage, whereas "Change content model" is not an option given (and probably shouldn't be).

Believe not supporting editing a previous revision of in a different contentmodel is problematic and probable on high-traffic mainspace pages. Twinkle's revert to previous revision would break here too, as far as I know.
@Legoktm remarked at VPR that a potential mitigation is a "change tag that indicates the edit changed the content model of the page, which would then link to documentation about changing content models".