I agree with use of <main>.

There's a skin specific sticking point, though. In Vector and Monobook, there's already a <div id="content" class="mw-body" role="main"> element further up the tree. This div includes .mw-parser-output, but also the #siteNotice, h1#firstHeading, #siteSub ("From Wikipedia, the free encyclopedia"), and #jump-to-nav (the visually hidden "Jump to: navigation, search").

Modern skin is similar, but with a <div id="mw_content" role="main">. In CologneBlue, it's <div id="article" class="mw-body" role="main">.

A page should only have one main region. So if a <main> is added, at the same time, role="main" should be removed from whatever elements in whatever skins have it.

It's also debatable which top-of-page material belongs inside the <main> and which parts don't. If you think an element other than the current div[role="main"] should be the new <main>, go for it.

Special note on Minerva: Minerva has no element with role="main", and therefore has no main region. It also uses the HTML5 specific elements <nav> and <footer> already. So, out of all the skins, I'd say Minerva most needs a <main>, and least poses a problem with adding a <main>.

Note that Parsoid also generates the mw-parser-output div (I believe) and so should also be changed to use <main> if/when this change occurs in the PHP parser.

We can also have multiple mw-parser-output per page, seems like a bad candidate to move it to <main>

Are you referring to Flow? I created T175937 in which I suggested that the divs in Flow with the mw-parser-output class become article elements. Is there anything preventing mw-parser-output from being an article if the content model is flow-board, and otherwise being a main?

@Nirmos Flow is one of them yes and i'm positive there are more. Especially in the future with multi content revision. I think it's very clear. mw-parser-output means nothing more, than "this came out of the wikicode parser". We have this specifically, so that we can scope the styling of user generated content to such blocks, to create separation of content and presentation. It is therefore incorrect to attach a presentational/layout concept to it. It's fine to have them as mw-parser-output blocks inside of article elements. Or to have mw-parser-output as a class on an <article (if it truly only contains content, which is suspect would be rare). But that latter probably needlessly complicates the page construction and caching.

Ok, so what if:

• The tag with the class mw-parser-output defaults to being a div
• wikitext pages explicitly pass "main" to ParserOptions::setWrapOutputTag()
• flow-board pages explicitly pass "article" to ParserOptions::setWrapOutputTag()

Does that address your concerns?