I'm not sure Nix will be very effective on a proprietary platform where updates can be forced on users, where you can't necessarily roll back, because it's out

I'm not sure Nix will be very effective on a proprietary platform where updates can be forced on users, where you can't necessarily roll back, because it's out of your control - and where the licensee can forbid you from distributing old versions. Trying to make Nix work on windows would require making up "psuedo-packages" for components of windows, where some hash of the binaries is used to identify them - one problem is we can't guarantee that components in windows can even have an identity which is common between installs - there could be a significant amount of unique configuration embedded into each install of the OS, which would give unique hashes, making it ineffective to even bother trying to make package trees where dependencies are exact - every user would need to maintain their own tree. If anything like Nix were to come into windows, it would probably need to come out of Microsoft to be effective - they'd need to acknowledge the merits of Nix and decide to push updates through a similar model. CoApp was of interest because its author was in Microsoft, and had potential to make an impact on the way software is delivered on Windows - it used separate shared libraries for each dependency without dumping them into project folders (by making effective use of the SxS technology in windows). It also required packages to be signed, which would've provided some of what is necessary in a model like Nix's, and in CoApp, each package is maintained in git, in a separate repository from the original projects. It looks like CoApp is still being worked on, although there's little activity - Nuget basically pushed this project to be stillborn, because Nuget provided an immediately convenient solution to the woes of Windows developers, without actually solving package management - the rest of Microsoft jumped on it and CoApp was ignored. Perhaps the downside of CoApp is the requirement to support Visual Studio, and to not acknowledge the existence of mingw/msys, which are really a requirement for building many projects, and the effort to port these builds into VS is non-trivial. I agree that cygwin is not a solution, it shouldn't be considered as such as it's more like the windows equivalent of WINE. Mingw/msys suffers from nearly all the same woes as the rest of windows, although it now has it's own "PM" (mingw-get), which is an improvement over the way things were done before then, mingw-get isn't a very sophisticated PM, more like a specialized downloader. This goes against what i just said above, but I think any potential solution on Windows needs to be liberated from Microsoft (and MS specific toolchains) - that is, a solution built around mingw and msys, whereby the mingw base packages become the bootstrap packages for an immutable model, and where those packages can reference Windows components with some alternative means to give them identities other than hashing of binaries - for example, the PM could provide some way to override the requirement of hashes for dependencies, granting that special permission only to mingw packages. The rest of user-land software would be built with mingw. Of course there is conflict here on building with VS versus mingw - the binaries produced by each aren't really compatible at all, so the use of both would require a dual build system. There's something out there like this - the KDEwin project, which has packages for both toolchains - however, there is still significant work needed to improve the state of KDE on windows, and the PM itself. Nobody is really suggesting that we don't use Babel, or that Nix is going to replace it overnight - you're absolutely right that getting something like Nix on Windows will take monumental effort, but we're sharing ideas for more long-term solutions to packaging problems, which continue to get more complex, and tools like Babel don't actually do much to solve that growing complexity.