Nix's raison d'etre is building packages in as much isolation as possible. When building packages, HOME is set to /homeless.
However, for setting up stuff in $HOME, there's a popular tool which uses the Nix expression language as its configuration language: home-manager. Even then, home-manager is more about using nix to configure programs. (I use it to symlink dotfiles). Nix's default is "the stuff it symlinks is read-only".
For "ensure this directory exists", I'd have `mkdir -p <dir you want>` in your shell's init / rc file.
Nix (or NixOS, really), on the surface, looks like a configuration management system and a packaging specification had a functional programming baby.
Now, I'm a systems engineer who generally writes in easy-to-use languages. I've used Arch the past decade and have used a variety of tools to automate my personal systems. My team is composed of systems administrators and network engineers who transitioned into devops-esque roles. Part of the purview of our jobs is to use configuration management systems to codify OS state. This could either result in an immutable image or mutable state on a long-running piece of field hardware.
Nix looks like a potential replacement for something like Ansible/Packer and there are a variety of projects hitting the front page of Hacker News that semi-presents it as a replacement (stuff like nix-ops or image to cloud pipelines).
So as someone who codifies system state as part of their day-to-day job, I'm looking at NixOS as a potential alternative. And there seems to be ABSOLUTELY no community support or documentation for learning Nix from a systems administrator point of view. Which is absolutely maddening because I'm an individual contributor that decides how packaging is done within a organization. Everybody in my team looked at Nix and said "this is absolutely impossible to use - we are literally never going to use this to support our organization."
And that's mostly because there is no guiding principle for how to adapt your mental model to think about the new paradigm if you're coming from something like Ansible... and there is no structured documentation for how to produce an OS state when what you know is YAML blocks or a Ruby based DSL.
I mean, it feels like the bones are there: you use Nix to install packages, start services, configure network interfaces, manage the kernel, etc.
But it also feels like Nix was built by functional programmers for functional programmers - with no UX for the people who would actually manage operating systems within a technical organization. Your syseng team isn't going to be functional programming whizzes. They're going to know Go or Python and be able to do medium-difficulty leetcode problems.
Honestly, there needs to be a "NixOS for Ansible Programmers." And if it's absolutely apples to oranges, then that needs to be communicated upfront somewhere.