Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's not a fatal flaw, it's just a regular flaw.
Docker files are basically "copy these files in and run these commands with full network access" which is a recipe for both "easy" and "not reproducible"
Oh, I need python? "RUN apt-get install -y python" done. Which python version is installed? I don't have to think about that.
If you want to ensure the inputs are the same, then you need to impose structure. That structure is a large part of what is confusing with Nix.
I hate the Nix language as much as the next-guy, but I don't think that if it were Javascript instead, everyone would be like "oh this is so easy!"
Compare that with Snap packages: https://snapcraft.io/docs/python-apps
Where everything is closer to true configuration not declarative programming. Apt and PyPi packages in, snap package out, install it like it was an exe or put it in an app store, give it some permissions, done.
They don't introduce any new concepts and there are few intermediate extra steps, it's all more of less pretty common ideas found in any tech workflow.
I generally think the UI first approach is a better way of building tools, but there are special cases where it doesn’t work due to their being so many edge cases that you need pure underpinnings to make it actually work (e.g. version control).
I ~empathize with people who wish it were simpler, and agree there are too many sharp corners. (For example, the traditional CLI certainly left a lot of room for improvement.)
I can vaguely imagine the prospect that something new gets this more-right than Nix, but on some level I also suspect most ~complainers aren't appreciating the scale of the domain complexity Nix closes over in order to forge The Nix Way and square decades of contrary software development/packaging/deployment practices with it.