There has been some back-and-forth on this, so maybe it's worth to go through the use cases in detail.
- Main wikitext: should be visible, but it's the main slot. (The long-term structured data UI plans would actually hide it behind a tab, but I imagine we'd want to do that with Javascript while still keeping the content in the default HTML view.)
- Structured media info: should be visible.
- Infoboxes and similar "page widgets": typically, the infobox should be rendered inside the article, and not as a separate content block, so as far as MCR is concerned it should be invisible. There might be exceptions (e.g. Winter-style skins) but there it would get some kind of special handling.
- Categories: should be invisible, as categories are handled in a different way, not via ParserOutput, and we probably don't want to mess with that.
- Other metadata: in the case of interwiki links: same as categories. (Also these usually come from Wikidata so cannot be handled on an MCR level.) Other types which aren't visible currently (NOINDEX etc): should be invisible, there is nothing to show.
- Documentation subpages (template + module): should be visible, this is really the main content of the page as far as viewers of the template page are concerned.
- Template styles: should not be visible by default, it's similar in function to the template source code (which we also don't show).
- Video subtitles: unclear. If we put subtitle translations in their own slot, those definitely shouldn't be visible. Chances are subtitles should be rendered by TimedMediaHandler on top of the video and not be visible as far as MCR, Article::view and other generic code is concerned. OTOH some video players put the subtitles below the video (e.g. this older look for YouTube), for navigation and for the benefit of search engines, so that would be an option (same for audio transcripts).
- Page collections: this doesn't seem like something that should be handled by MCR, actually.
- Article assessments: unclear. Could keep the current template-based display, and just make the way the data is stored more standard; or the assessment box could be generated by the extension in which case it would probably be displayed as a separate slot.
- Image focus areas: should not be visible, this is not something that can be meaningfully shown to the reader. Even if we store the image + focus area together as a slot, the way the image should be shown needs to be deeply integrated with the skin, so it has to be hidden as a slot and then rendered by some other mechanism. If the skin doesn't support article banners, it shouldn't be displayed at all.
- MassMessage target lists: these will be main content slots.
- CentralNotice CSS/JS/HTML/wikitext fragments: presumably the default view we want here is to show the banner as it will look in the article, and not the various pieces of source code? But could see this going either way.
- ProofreadPage: unclear. Currently this just concatenates header, body and footer before parsing wikitext, not sure of the pros/cons of keeping that vs. displaying each slot separately. Anyone familiar with ProofreadPage usage patterns?
- Gadget files: unclear. Could show everything on the same page, or just show the gadget definition and link to the individual slots, to make the page size more manageable (imagine a gadget that pulls in a 30K external library, you'd probably want to look at the locally authored files without having to scroll through that).
- Workflow state: probably should be visible.
- Wikidata description override: should not be visible. (Wouldn't make sense since the description isn't either. Even that does get displayed, that needs some non-slot-based mechanism as the text can come from Wikidata.)
- Annotations: these need highly specialized display integrated with the main content HTML, so should not be visible as slots.
- Page forms: should be visible.
- Blame maps: should not be visible (not even as hidden-but-included-in-HTML as these tend to be huge).
- OCR text: should be visible.
- Files: should be visible, but probably it would be the main content slot for file pages if we do this refactoring.
- Rendered HTML: does not seem terribly likely that this will ever happen as part of MCR.
So that's 5 use cases for non-main slots which should be visible by default, 8 which shouldn't, 5 in which case either approach seems reasonable.
Does that seem like an OK tally?