If I understand correctly,
pkgs.pkgsCross.musl64 is technically a cross compilation toolchain, which uses a compiler that is itself linked against glibc, uses a bunch of platform triples everywhere, and outputs binaries that are linked against musl. This is surely still some kind of bug in one of many possible components, but likely caused by cross compiling being weird.
$ ldd $(nix-build --no-out-link "<nixpkgs>" -A pkgsCross.musl64.stdenv.cc.cc)/bin/x86_64-unknown-linux-musl-gcc
libm.so.6 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libm.so.6 (0x00007fb7db9f6000)
libc.so.6 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libc.so.6 (0x00007fb7db840000)
/nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007fb7dbb8e000)
Notice the triple in the compiler binary name, and that it’s linked against glibc, even though the
stdenv will produce packages linked against musl.
pkgs.pkgsMusl, on the other hand, is just a normal package set that just bootstraps a compiler the normal way, but replaces glibc with musl everywhere.
pkgs.pkgsMusl.xorg.X11 built just fine for me, and got a lot more from the binary cache than
$ ldd $(nix-build --no-out-link "<nixpkgs>" -A pkgsMusl.stdenv.cc.cc)/bin/gcc
libc.so => /nix/store/javypr9lls4hm88znp4mcyp78qphgpzx-musl-1.1.22/lib/libc.so (0x00007fd352751000
Notice that the gcc binary in use is itself linked against a
libc.so from musl.