Yes, you just need to output something that contains an executable that will be run by the consumer. That executable may as well be “run $SHELL with all the environment variables from this attribute set”.
Arbitrary packages will be arbitrary packages. You can hope that upstream authors will put executables into /bin and that Nixpkgs may expose a meta.mainProgram.
Nix proper doesn’t have a notion of anything more sophisticated than file system trees. The constraints imposed by all that comes with flakes are quite opinionated, and that’s intended. But one reason none of that is stable is that – from what I observe – it’s by far not universally agreed-upon by maintainers of the ecosystem.
Ideally we’d finally come up with a Nixpkgs convention to derive composable environments from packages, the last effort around that stalled: Nixpkgs CLI Working Group Member Search Help appreciated!
From experience, it’s much easier to work up from pure Nix expressions and wrap that in flakes when needed than doing everything monolithically first and then refactoring the other way around. The example you’ve posted primarily uses Nixpkgs facilities, and only needs flake references to pull in remote sources.
This can be separated into the business logic that produces file system trees (Nixpkgs package recipes, or whatever really) and any mechanism to provide file sources for these recipes. mise could even have its own?
Also, enabling backwards compatibility is really not as easy as you’d think. Forward compatibility on the other hand is not just trivial but actually beneficial for code organisation and conducive to different ways of consuming the code.
In any case, I’d personally advise against baking flakes into everything by default. It’s a usage paradigm for Nix that is pretty much oriented towards end-users of closed systems rather than developer-users of library components, and it seems to me that you’re trying to facilitate the second use case here.