while this is cool work, I'm not entirely convinced the pros and cons weigh up: if I understand correctly, the advantage of this approach over #420575 is that it avoids (mass) rebuilds when only the (exposed) metadata for a package is changed. While that's attractive, requiring a whole new nix feature for it seems rather heavy: it adds complexity to nix, and would likely require a substantial testing/stabilization process before it could be enabled by default in nixpkgs.

I wonder if it wouldn't make more sense to do something along the lines of #420575 , and in parallel focus on content-addressed derivations for reducing rebuilds? that will also take a long time to stabilize, but it will reduce mass rebuilds not only for metadata changes but for a much wider range of 'irrelevant' changes.

In any case, either this approach or renewed activity on ca-derivations could be great, but perhaps we shouldn't allow it to block #420575 ?

whole new nix feature

adds complexity to nix

Barely any. If anything it makes Nix more predictable because this further breaks down the myth that outputs would have unique derivations that create them.

a substantial testing/stabilization process

It's a small feature, unlike the easier-to-understand work like the new CLI or Flakes that you're used to thinking about.

and in parallel focus on content-addressed derivations for reducing rebuilds?

I wouldn't have realized (both meanings) this possibility if it wasn't for documentation work on CA.

ca-derivations is a larger feature, and its experimental phase has shown the need for multiple changes.
Modulo meta is simpler and could easily be completed before CA derivations, with minimal effort.

Also note that hash modulo is orthogonal to CA derivations, and even when we have CA derivations, input addressing will still serve its own purpose for builds that do not have rewritable outputs, or which don't have the right workarounds in place.

So we have three features of increasing complexity and usefulness.

1. meta in output hash
2. meta outside output hash
3. ca derivations

2 and 3 are mutually beneficial, but 1 -> 2 requires changes in derivation tooling.

Doing 2 and 3 is less total work than 1, 2 and 3, and skipping 2 means we have some unnecessary rebuilds and no progress on the timeouts issue.

I strongly suggest we do 2 and 3, but if we urgently need a temporary meta extraction functionality, I won't stop you from also doing 1 if you accept that the format will be improved.