Comparing nix style (hash head, package tail), and spack style (package head hash tail), and speaking from my own limited experience, the need arises in different cases, which also depends on the ease of tooling,

sometimes I'm grepping in /nix/store and you have (as shown earlier) a list of derivation paths like this

$ ls /nix/store | grep nodejs-2 | head | sed 's/^/ /'

    0a9kkw6mh0f80jfq1nf9767hvg5gr71k-nodejs-22.18.0.drv
    0pmximcv91ilgxcf9n11mmxivcwrczaa-nodejs-22.14.0-source.drv
    0zzxnv3kap4r4c401micrsr3nrhf87pa-nodejs-20.18.1-fish-completions.drv
    2a7y7d38x8kwa8hdj6p93izvrcl9bfga-nodejs-22.11.0-source.drv
    2gcjb0dibjw8c1pp45593ykjqzq5sknm-nodejs-20.18.1-source.drv

and thus as designed, your eyes ignore the block of hashes and you see the "nodejs-..." stuff

You might ask why are you grepping? Because it's fast and familiar and I don't know the native tooling as easily (possibly a UX problem).

Then in spack (see https://spack.readthedocs.io/en/latest/package_fundamentals....) they have

$ spack find --paths

    ==> 74 installed packages.
    -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
        ImageMagick@6.8.9-10  ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/ImageMagick@6.8.9-10-4df950dd
        adept-utils@1.0       ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/adept-utils@1.0-5adef8da
        atk@2.14.0            ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/atk@2.14.0-3d09ac09

and

$ spack find --format "{name}-{version}-{hash}"

    autoconf-2.69-icynozk7ti6h4ezzgonqe6jgw5f3ulx4
    automake-1.16.1-o5v3tc77kesgonxjbmeqlwfmb5qzj7zy
    bzip2-1.0.6-syohzw57v2jfag5du2x4bowziw3m5p67
    bzip2-1.0.8-zjny4jwfyvzbx6vii3uuekoxmtu6eyuj
    cmake-3.15.1-7cf6onn52gywnddbmgp7qkil4hdoxpcb

you get the package name immediately from the left, which is nice, and you can pipe that straight to `sort`, but where the hash starts is more jagged on the right so there's a bit more noise when you're looking at the numbers. In the end the information is identical and it's a UX difference.

Tradeoffs wise I think they both made the right choice. Because for nix, the packages are almost always in /nix/store, so the path length including the hash is almost always the same.

For spack you can place your packages anywhere so the base directories can be highly variable, and so it's sensible to have the package names immediately after the package directory.

Or, I'm just trying to rationalize the choices each designer made post-hoc. But after using both I appreciate the design considerations that went in. In the end, humans are inefficient. When I make name / version / hash identifiers in my own applications I end up using one or the either design.