This is a red herring; Linux isn’t a monorepo and they don’t have this vague “problem of trust” that you allude to. And after the XZ debacle I think the whole “it’s on github so I can trust it” myth is dead too.
The real obstacle is that desynchronized development, like kerneldev uses, requires conscious effort. You have to adjust your development style to deliberately avoid things that will cause merge conflicts. Right now nixpkgs interleaves version bumps with (sometimes OCD-driven) treewide style changes, which makes anything other than “merge as quickly as you can” miserable.
It doesn’t have to be like this.
Without any changes to Nix, there is an architecture which avoids rebuilds when a dynamically linked dependency changes, so long as the symbol table of the .so file does not change (i.e. set all symbols to zero length) which covers basically any change other than a version bump. This is different from both pkgs.replaceDependency and also from guix’s grafts.
This does not require content-addressed derivations. However it does require a strict hygenic separation between the buildPlatform and the hostPlatform essentially equivalent to cross-by-default.
Both of the above changes (development style and symtab-hash dependencies) have an incentive problem. They are positive changes for nixpkgs in the long run, but since they make it easier to maintain competing forks those who manage the monorepo are disincentivized to adopt them. Also, both changes require a substantial amount of real work.