What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible.
That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.
> What exactly would this "cleaner base" look like?
My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix.
This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix:
1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or
2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging)
And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing.
It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.
The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper layer, and newer ones should hopefully work in a more natural way.
Guix and Hurd and whatnot try to be more pure about things and look how far it got them. There are tens of thousands of projects that would basically need to be redesigned and written from the ground up to achieve what you desire, and I think the best approach is to build the platform and prove its value and create a path and model for new projects to follow. There are only so many open source developers out there.
And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base".
While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too).
The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request".
So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.
My experience with Nix is that my own tools didn't work, even with the help of Nix experts. Then, after months of debugging we figured out that I had to quit vscode completely, and then start it from the console using the nix command with the -i option to clean up any environment variable (without that option it wouldn't work). There were some nix plugins for vscode, which would have been awesome if they had worked, but they didn't.
That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.