Just to add my €0.02:
It's probably better to think of the moss toolset and related release engineering process as a way to create curated packages that form a cohesive whole, rather than creating flexible meta-packages that introduce a combinatorial explosion of test cases. The goal is to enable the creation of cohesive products or spins with good ootb defaults, such as a competent KDE desktop spin just to name one example.
The idea with having a local repository and being able to consume source-only lightweight .stones is mainly to be able to ergonomically develop and test stack upgrades and new packages quickly, and to be able to conveniently A/B test performance-related compilation and linking flags for existing upstream recipes.
In many ways, we are aiming to become an alternative to (but not necessarily a replacement for) Arch and Fedora, with our USP being a keen focus on performance testing and thus enabling the delivery of a curated rolling distribution with built in efficiencies in terms of building and shipping performant packages.
In some ways you could say that we might also cater to a subset of ex-Gentoo users, who might just want the ability to use a system which automagically builds, rebuilds and installs a specific set of packages (which could potentially, as you suggest, be the entire system set of packages) with -march=native and CFLAGS="OMGSPEED!" as necessary, but who don't want to painstakingly maintain an entire distro or even custom recipes.
Conversely, if you want what Gentoo, Nix, Arch or Fedora offers, use Gentoo, Nix, Arch or Fedora.
Out of curiosity, what is the use case for running with local patches? From my perspective, this is only really useful for development and testing; if something is "better" than what the relevant upstream/official recipe carries, things ought to be upstreamed as appropriate or, alternatively, forked as an alternative recipe that provides the same thing as the original/unmaintained upstream.
Again, keep in mind that I see this from a "how to create a cohesive product" PoV, not a "my particular pet distro composition is a sample of one" PoV.
As a final note, all of this is in flux. This is my personal vision. The end product moss tooling may end up being slightly different and/or better than what I outline above if Ikey has/gets a better idea.
