Most of the time, the Nix interpreter version is independent to the evaluation result. People would base their daily-driver on NixOS/nixpkgs/nixos-<stable version> and get bleeding-edge versions of packages from NixOS/nixpkgs/nixos-unstable directly without hesitation. This does not hold when a new builtin function is used in the newer version of Nixpkgs (or other Nix projects) but is not available to the version of Nix used to evaluate it.
As new builtin functions are added to newer versions of Nix, when is it considered okay to be used inside Nixpkgs? We don’t seem to have a guide about it.
To be specific, builtins.convertHash recently got accepted and merged into Nix. It would greatly simplify the implementation of legacy hash arguments (e.g. sha256 and sha512) compatibility of fetchers. I would like to know when to submit such PRs.
The lib/minver.nix file specifies the minimum Nix version required, which is currently still 2.3. As far as I know there’s no standardised process or guidelines for updating it though.
Furthermore, CI doesn’t even use that version of Nix most of the time, so changes making Nixpkgs dependent on newer features might not even be caught, which caused problems before when placeholder was introduced.
Furthermore I’d encourage people to not use builtins directly, but rather put their functionality into lib first and then use it from there. Builtin functionality being available through lib makes it much easier to evolve them over time, since we’re not bound to the indefinite stability guarantee of Nix builtins.