I don’t have a direct answer, but an idea that has come up before does use the registry, and goes like this:
My nixos system flake has inputs and a lock file. When the system is built, entries are added to the system registry of the new closure, pinning those inputs. I do this today, mostly to avoid ad-hoc nix shell and similar commands checking and re-downloading the sources.
What I would like is a version of nix flake update in a project workspace that takes the same revisions from the registry, even if they’re slightly out of date. This means that a number of projects will get updated all to the same versions of build tools, and those will already be on my system together with all their dependencies. If there happens to be a giant rebuild after a staging cycle lands, I won’t accidentally wind up with surprise downloads and different versions in the middle of the afternoon (unless I want to).
I don’t want something that builds an implicit / impure dependency on the registry, just regular locking but with a different selection mechanism at the time of update.
Keeping registries in sync across machines is then also as easy as keeping them up to date with the same system flake.
This doesn’t work so well for other inputs that aren’t part of the system flake, however.
Edit: I found the previous post, which has some details about how the existing setup to set nix registry and paths as part of build works: Using nixpkgs.legacyPackages.${system} vs import - #19 by uep