Very interesting write-up, thanks for sharing it, I think I can relate with my own experience before adopting a different approach that I am going to share here.
Given what you are trying to achieve, I think you should definitely have a look at Den, twice.
From what I understand, your direction already matches the core idea behind Den: moving away from a host-first configuration model and making aspects the primary unit of composition. In your post, you mention several pain points that Den seems specifically designed to address (in a very graceful way!):
- composing NixOS and home-manager concerns from the same logical aspect
- avoiding duplicated wiring between NixOS, standalone home-manager, and potentially Darwin
- making host configurations additive rather than centrally dispatched
- reducing the amount of manual
specialArgs, fakeosConfig, overlays, and package plumbing - making relationships between aspects explicit instead of relying on scattered
enableoptions - keeping the door open for custom module classes or non-standard contexts
The nice thing with Den is that it takes the dendritic idea further: an aspect can provide configuration for several classes at once, for example nixos, homeManager, darwin, or even custom classes (terranix (demo), nix-darwin,…). So instead of modelling “Sway for NixOS” and “Sway for home-manager” as related-but-separate registry entries that you need to wire together manually, Den lets you model the concern as one aspect that can provide different class-specific fragments.
That seems particularly relevant to the multi-context aspect problem you describe. Den’s context-aware dispatch also looks like it could remove some of the awkwardness around passing host/user data around through specialArgs or fake structures. The host/user/entity context becomes part of the resolution pipeline rather than something you have to manually thread through every layer.
It also seems like a good fit for your standalone home-manager case. Since Den is not limited to a “NixOS host owns everything” topology, a Fedora + standalone home-manager setup does not have to be treated as a weird exception. It can just be another entity resolved through the same aspect model.
The main caveat is that Den is still quite advanced and probably adds its own conceptual machinery, so it may not be the simplest migration path (see mine: refactor: switch to `vic/den` framework by drupol · Pull Request #124 · drupol/infra · GitHub). But given that your post is already exploring factories, interface aspects, multi-context aspects, custom package exposure, and cross-cutting concerns, I suspect you are exactly in the part of the design space where Den starts to pay off.
If the dendritic pattern is the direction you want to take, Den might be the framework that gives you most of the missing pieces you are currently trying to design yourself.
Get started at https://den.denful.dev/
Join the discussion on the friendly Matrix space: https://matrix.to/#/#denful:matrix.org
Also, read pain points I encountered with Den at Evaluating Den - A Dendritic Configuration Framework | Not a Number and Den Framework Follow-up: Issue Fixed ! | Not a Number (#self-promotion-ftw)
Good luck!