Why skins? Why not let people just mark modules as 'stylemodules', not worry about what the hell is providing them, and then not add them to the giant js bloat pile and be done with it?

@Isarra That's an interesting idea. Roan had the same idea a few weeks back. Unfortunately, that's not compatible with how MW works. All style modules must be loadable on-demand. A number of systems depend on that. The only exception to that are skin modules, hence this proposal.

Regular style modules from core and extension features that style HTML output, are enqueued through ParserOutput, which mw.loader.load() needs to be able to translate into an on-demand requirement. Used by Live Preview, VisualEditor (while editing after inserting new nodes, as well as post-save for the new version of the article), and possibly in future lazy-loading endeavours. In cases like these, there is addModuleStyles() calls made on content that is saved in the ParserOutput, but served through the API to a JS client (instead of as a regular page view).

@Isarra That's an interesting idea. Roan had the same idea a few weeks back. Unfortunately, that's not compatible with how MW works.

Comments like this really aren't helpful. If you have counter examples that show something won't work as described, please just start with that and avoid telling people that their ideas are just bad, and also someone else already beat them to it. Not only is this really not necessary, it is frankly very off-putting and discourages productive discussion or collaborative working toward a better understanding on all sides. (For instance you could just say 'Roan brought this up and we looked into it and we found ... <content example>' and suddenly all the 'how interesting, you clearly don't know how mw works' implications are gone.)

Even in this particular case, that is only one specific example. Do we really have no other module categories beyond 'this skin', 'content and things that could become content', and 'javascript'? Do no extensions add base interface styles besides skins, that will just be there from the start?

If the problem here is that the list has gotten out of hand, do we have any reason to expect it won't keep getting more so, even with this one category removed? Why not categorise the modules in terms of when/how to make them listable/loadable? Instead of a giant list of modules, have a list of categories of modules, and only load the categories that make sense from the start (no content on non-content pages unless explicitly requested, no skins that aren't the current skin, don't get the rest of VE until people actually load VE), but let the js go get the other lists as needed (like if we added a fancy skin preview in special:preferences, configuresite, whatever, we'd maybe load the skins lists there after all, but we still likely wouldn't need it anywhere else). Each skin becomes its own category, most extensions just add to standard categories like 'content' or 'interface' or whatever, more complex extensions like VE define new categories probably with the same interface as skins use...

I'm sorry that my comment discouraged you, this was not my intention. The emphasis and tone of words are sometimes hard to receive through the written word...

I specifically choose to reference our previous work to motivate your thinking along these lines. The idea was very much not "clearly wrong". On the contrary. It was something we also thought of (thinking alike) and took seriously. We found the aforementioned issues, but that doesn't mean it was obvious. Your idea was independently thought of and demonstrates you understand the system's intent and model quite well. There's not many people whom I can say that about.