In reply to @brian:bmcgee.ie
I lean more Domen Kožar's direction on this one for the simple reason that the majority of my 2 years with Nix has been flake-oriented. The only time I write a shell.nix is to make a project compatible for non flake users. There are valid concerns about flakes and a need to stabilise them. Maybe I'm putting effort in the wrong place and should be helping to stabilise flakes like you said infinisil rather than putting effort into documenting a workflow I choose not to use on a daily basis (and I say this without any kind of snark or ill feeling).

Just to provide another datapoint: I have spent my last years removing Flakes from project (latest example in mind is bcachefs with an impossible Flake setup…), dealing with people who tries to shoehorn Flakes into the wrong project because it is not fit for it, dealing with a lot of kind of footguns generated by deep dependency management brought by Flakes, etc.

While I do understand the value of Flakes and use them sparringly or have projects with them, I am not excited to see documentation team having to focus on that, especially given that most people does not know how to do things the vanilla way (sometimes people do say the "legacy" which irks me the wrong way, because Flakes does not supplement the vanilla usecases yet, for example, try to repair your remote store with the "nix-command" CLI :))