I will add another caveat to this - mixing stable and unstable is pretty much unsupported, so you are even more on your own* than using just one channel exclusively. And of course having multiple nixpkgs instances comes with its own performance and incompatibility problems, especially for GUI apps and “core” dependencies - complaints around glibc or qt version mismatches are common here.
One other option for people that want to use stable would be to use a scheme similar to what I use for unstable - a long-running fork of nixpkgs wherein I can pull in PRs and make my own fixes directly in the code. Updating the branch consists of fetching the corresponding upstream branch (either nixos-unstable or nixos-YY.MM) and then rebasing upon it.
The main benefit is some familiarity with the codebase and being more resourceful than having to simply wait for others. It also could result in less work than using unstable directly since you avoid the frequent breakages of unstable, while allowing you time to essentially backport your own fixes that you care about. The downside of this approach is that less is cached by Hydra and more is built locally, of course, but it prevents the abovementioned version mismatches. Additionally since it’s an untested zone, you would have to figure out any fixes on your own*.
That’s fair, depending on your usecase. I don’t have a good solution other than what I do regarding the long-running fork, which I recognise is even more manual work and puts you on your own* in a different way.
*I mean you can ask here on Discourse if you need help of course, but I mean it’s not something that nixpkgs itself will concern itself with supporting.
(Also, another unfortunate thought I just realised: nixos-unstable is not actually supported by nixpkgs - really the only supported branch is master, which is also one of the worst branches to use for a NixOS system, since nothing that changed recently is cached or tested.)