I mean … I bundled all my plugins into my theme and I suppose I could parameterize everything theme-related and register it, but I'm guessing I wouldn't be able to version my personal configuration files via GitHub repository any longer and apply them on top of the theme … so I'm pretty sure it wouldn't be worth the effort. The problem here really seems to be that everything is a Hugo theme by nature, the distinction between components is being arbitrarily layered on top. There is no reason, for instance, that a single Hugo generated Micro.blog site cannot apply multiple theme components (which in fact they do, we call them plugins). There is no reason the order of application could not be configurable. The illusion of structure works to simplify some aspects (like plugin configuration preservation) … this is far outweighed, however, by the limitations it imposes (like what those plugins can actually do or just how configurable they actually are). The answer to this continues to be the rebranding of the custom theme into what it oughta be, the root site configuration. It preloads with the blank theme. Users can add anything they can now to a custom theme … and these files should override installed plugins/themes. File naming should be deliberate as a general rule amongst plugin and theme developers so as not to incur naming collisions. In this way you can build your site up piecemeal while maintaing the last word as to what the final parameter values (or the templates themselves) should be. And, yes. This Micro.blog site configuration should be loadable from a repository so that everyone can enjoy version control over changes to their own site. cc @manton @sod @pimoore @whoeverelse