Earlier quoted context omitted.
... except that (a) WSLv2's kernel will be running in a VM, and (b) macOS's kernel is much more like Linux's -- fork/exec, networking, filesystem, memory, TTY. I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.
NT supports interfaces for supporting a fork model efficiently, it's just not well documented. In fact, you can write an efficient, Windows-native POSIX environment entirely from user space using existing APIs: https://midipix.org/ The only thing that NT really lacks is a Unix-style TTY subsystem. The interplay in Unix between TTYs, process control, and signals is complex and deep, and none of it lends itself toward…
The long, laborious ConHost / NT Console subsystem rewrite/refactor over the last few years has moved Windows a lot closer to the Unix PTY system for internal plumbing (while not breaking the NT Object side of things). The fancy new Microsoft Terminal in alpha testing now takes advantage of that.
> WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
I feel like this is an interesting case where version numbers hurt more than help, because it sounds like WSL1 and WSL2 rather than a pure 2 > 1 are going to be side-by-side for some time now (moving distros between WSL1 and WSL2 is supposedly a simple powershell operation and can be done in either direction) and hints from Microsoft that there may even still be additional investments in WSL1 depending on user use cases and interest.
I think it's good for the NT Kernel to maintain subsystem diversity, and so I do hope that WSL1 continues to see interesting uses, even if a lot of developers will prefer WSL2 more for day-to-day performance.