TL;DR: I don't get it. Why bother with Windows at all if you are not going to use it anyway?<p>Ninja-addition: but don't get me wrong, the writeup is quite nice anyway! And if you are in a mixed environment where you need to run MSBuild locally for win32 apps and do a small amount of local-linux it might make sense.<p><slight-rant>
Windows isn't a nice self-hosting toolbox OS with *nix semantics and probably never will be, no matter how much emulation or subsystem layers are added. In a way, macOS is moving a bit in that direction as well, but without killing the foundation it is built upon. Perhaps, if at some point either the NT kernel gets replaced (no, it's not a bad kernel, it's just a 'different' kernel with no compatibility towards BSD, Linux, Unix, Mach, L4, or any other open kernel) it will allow for a more toolbox/developer-centric environment.<p>Now, while this argument might seem like the one about "I need things to be open source because I want to touch it" (which gets stale pretty quickly since 50% of the users never do this or probably don't even have the skills), it's not what I'm aiming for. It's more about the fact that you can interrogate, manipulate and visualise all levels of the system you are working on, in an identical way you can do on your target system. While most types of actions have comparable methods on Windows, there is nothing like a /sys /dev or /proc on Windows, you can't easily 'see' what you are doing, and that is a really problematic thing once you get past the entry-level web development. Most of the inspection and introspection on Windows comes in the form of closed source bulky IDE's that may or may not have that single feature you needed to figure out why your program has trouble reading some device node or why it's performance varies depending on connections, handles or other OS-dependant actions. At best, you can do some stuff with the sysinternals suite, but that doesn't even come close to basic tools like top,ps,lsof,sysctl,ldd,strace,gdb. The whole Windows ecosystem is so tightly bound to opaque systems that cannot be reached unless you dig around in some GUI, it makes it hard to do basic debugging. While it has gotten better over the years, we are still stuck with a ton of half-invisible things in ancient GUIs or MSC plugins that have an impact on your work but have nothing to do with your target system. Basically, you now have to maintain two systems of which one isn't really the one you wanted to work with in the first place.<p>It's not that you can't do it, it's just that much harder to do on Windows. This is not unique to Windows, and applies to smaller scopes as well. If you build an application in an IDE and you want to automatically test and integrate it, but you didn't check how to build, link and package your product because the IDE did it for you, you suddenly can't reliably do what you needed to do, and you have to reverse-engineer the somewhat opaque process that the IDE did for you in the background and reproduce it using toolbox-tooling in order to automate it or deploy it on your target system. While not using that IDE isn't the super-solution either, purely depending on one blind/black-box integrated system is hardly the smartest choice out there.
</slight-rant>