omniflake puts about twelve thousand Nix flakes behind one input, and its author submits a quadratic lock-naming fix upstream

Sources: primary, project, discussion
Summary: Declaring thousands of flakes as inputs failed, because Nix evaluates every input to write the lock file and one unlockable input aborts the run. It was also quadratic: every flake brings its own systems input, so 4000 inputs produced nodes named systems_2 through systems_4000 with the collision search restarting at _2 each time, roughly 8 million string formats per evaluation. Zakaria's fix, filed as NixOS/nix#16387, remembers the highest suffix per name and resumes there, reports about 21x faster locking at 4000 inputs, and writes byte-identical lock files, while omniflake itself abandons inputs entirely, storing a JSONL table of locked pins and fetching each flake on demand with builtins.fetchTree at a cost of about 1.5s for nix flake lock and six inherited nodes.
Why it matters: The quadratic lock-naming path affects any flake with a large input set, independent of whether anyone adopts omniflake.
Follow-up: Track whether NixOS/nix#16387 is merged and which Nix release carries it.