The issues with nixpkgs stem from that it is a monorepo for all packages and doubling as an index.

The issues are only fundamental with that architecture. Using a separate repo for each package, like the Arch User Repos, does not have the same problems.

Nixpkgs certainly could be architected like that and submodules would be a graceful migration path. I'm not aware of discussion of this but guess that what's preventing it might be that github.com tooling makes it very painful to manage thousands of repos for a single project.

So I think it can be a lesson not to that using git as a database is bad but that using github.com as a database is. PRs as database transactions is clunky and GitHub Actions isn't really ACID.