those are excellent points. I don't personally have anything to add to that but I do agree they are minor.

if we had to go the subdirectory route, I would vote on "shards" or "sharded" though I have very little interest in contributing to the naming discussion more than I already have.

(I am avoiding pkgs/unit here or pkgs/shards not as a statement but to focus the sharding structure.) regarding GitHub's UI, my only potentially naive rumination on the directory structure is that something like pkgs/A/B/${name}/package.nix or pkgs/A/B/C/${name}/packages.nix could be adopted instead of pkgs/AB/${name}/packages.nix or pkgs/AB/CD/${name}/packages.nix. having one letter levels would enforce that each level has a maximum of 26+10+2 directories. GitHub could surely be agreeable to that experience. given that there's a very large group of packages with the lib prefix it might even be appealing to have pkgs/A/B/C/D/${name}/package.nix