When I first started looking at cross-compiling in Nix, I had a similar desire to be able to mix native and cross-compiled packages, but after seeing all the special cases required to make many packages cross-compile, I realized that solutions such as those mentioned in this thread would lead to all sorts of subtle bugs of the kind that Nix was created to avoid. The only sane way I can see to make this work would be cross/native reproducibility and the intensional store.
Personally, I think the best use of people’s efforts is to create, review and test cross-compiling related PRs so we can fix the last few broken packages required to cross-compile a practically useful NixOS system. Most of the necessary PRs have already been submitted, but need a little bit more work or have stalled for lack of reviewers. @samueldr showed that this is already possible with a couple of configuration tweaks and package overrides, but I would like to remove the need for any configuration changes.
We also need to prevent regressions, ideally by having ofborg and Hydra cross-compile packages. For cross-compiled NixOS to be practically useful, we need to fix a number of closure size issues, usually due to build arch references. For example, [WIP] gcc: put target-specific libs in lib output by illegalprime · Pull Request #58606 · NixOS/nixpkgs · GitHub fixes the issue where almost every cross-compiled package ends up depending on gcc. Many people do not check for build references when making cross-compiling PRs, so there are quite a few packages to fix.
I have a branch that consolidates a number of cross related patches (along with the other downstream patches that I use), but it still is not enough to cross-compile any of my systems.
The cross-compiling effort might benefit from some clear goals and organization, but I think the main issue is that there are relatively few people who have the skills and interest in working on cross-compiling, so things tend to move slowly.