What I’d like to see them do, is add more POSIX APIs to Win32 (not some separate environment like WSL is). It would make porting apps from Linux/macOS/etc to Win32 a lot easier, and remove the amount of code required in cross-platform apps/frameworks
I am an avid Linux user, but honestly I think Windows’ lack of POSIX is arguably a benefit.
I feel like POSIX has effectively codified mediocrity. It’s not “bad” but I don’t think it’s the be all end all either. Even NT 1 was arguably ahead of the POSIX standard.
You can have POSIX while having a radically different "not-POSIX" API. A good example of this is IBM's flagship mainframe operating system z/OS – it is a certified Unix, and recent releases have even added a big subset of the Linux namespaces API (to support Kubernetes), but that whole radically different mainframe world is all there too – and Unix processes have direct access to most of it.
The official Windows POSIX model – from the NT POSIX system, to Interix/SFU/SUA, through to WSL1/WSL2 – has always been that a process is either POSIX or Win32, never both at once. By contrast, the z/OS model is any mainframe process [0] can turn on POSIX mode ("POSIX(ON)"), gaining access to Unix APIs, but still able to call all the classic mainframe APIs.
This is also basically the Cygwin model. But the Cygwin team have to do all kinds of expensive and complex hacks to make it work, while Microsoft could provide the same functionality far more easily.
To give a real example – NT lacks an exec() system call, the ability to replace a process with another executable while keeping the same PID. So Cygwin fakes it by starting a child process, but then maintaining "Cygwin PIDs" separate from the NT/Win32 PIDs, and a child process started by exec() inherits the parent's Cygwin PID, so looks to POSIX code like the same process. Microsoft could just implement an exec() system call. Or if for some reason that's too hard, move this "two PIDs" thing into the OS kernel, where everyone would get it for free.
[0] not quite true, there are some special types of processes which operate in modes which are incompatible with the use of POSIX APIs; but your average/normal/run-of-the-mill process can.
Cygwin is literally what you describe - some companies (usually engineering firms who make high-end CAD software and the like) use to ship their Linux based tooling on Windows, you can use it, and most Linux CLI tools run on top of it.
It works well, if you mind the limitiations, but it has existed for a long time, and I don't think it's been a huge game changer.
Cygwin literally isn't what I describe, because it is an additional layer of code which isn't supported by Microsoft, doesn't come with Windows, and contains a lot of complex inefficient hacks to do things which Microsoft could do much more easily.
