I think the problem boils down to dependency resolution (which is an untreated problem in Nix). Nixpkgs works well because one commit is almost one consistent view of packages. Flakes, with their deep package management treatment, goes in another direction.
IME, most of the Flakes users have troubles understanding this and are confused to why their code becomes suddenly “”“non-reproducible”“” (their wording) again because the deep dependency tree has non trivial effects on the consistent view that we had in Nixpkgs.
I understand your frustration but for me, as a maintainer of FLOSS software with Flakes, spending my time on debugging other people’s code because they did a wrong follows or they want to do something unsupported albeit impossible to communicate or encode as impossible to do, is equally frustrating.
This is why we are calling on NOT steamrolling this even though it WAS steamrolled in the past. We all want some form of hermeticity of evaluation and dependency management, but as I said: this requires HARD work. This is the size of task.
Refusing this will simply put the implementers in a dead end.
See more about this topic: Haskell for all: The golden rule of software distributions.
It’s fine to desire for Nix to raise to the challenge of SAT solving and dependency resolving. I would personally recommend that the energy budget is focused on streamlining the uncountable amount of scalability issues and technical debt that was generated by Flakes introduction (and just generic codebase debt of a 20 years old codebase, which is fine! Debt has to be paid, though.)
Of course, we can rush into trying to run without knowing how to walk (my PoV of the situation), I will pass though ;-).