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.
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.