I wasn't primarily concerned with Windows portability, but with the portability of scripts altogether, and no longer having to concern oneself with variations i

I wasn't primarily concerned with Windows portability, but with the portability of scripts altogether, and no longer having to concern oneself with variations in coreutils versions for at least some scripts, even if they run on multiple platforms. But to answer your question about Windows: Because requiring an emulation layer is a huge step up in complexity from being able to distribute your shell as a single static binary which is just a few MB. Right now Elvish and Nushell, for example, can be deployed on Windows as binaries that don't require any external dependencies, any installation procedure, or any configuration. If they could link against uutils statically, they could also come with basic utilities without having an environment to manage. WSL (along with MSYS2 and Cygwin) is deeply stateful. Now to make sure everything is working you have to check the compatibility of your whole system, and the versions of coreutils can still vary in addition to the version of the shell interpreter. WSL2 also requires virtualization, which can complicate using it under virtual machines. You may not want everything you run under your shell to depend on WSL, which is also happens with WSL2. Even with WSL1, a script that requires a chroot environment to deploy and run it is way less portable than one that doesn't.