But I hope you agree that the wine analogy was quite misleading, and easy to understand as a WSL1 reference.
Is it? I mean, WSL2 does run the Linux kernel in a VM, letting the kernel interact with Windows using various protocols, so technically a large part of WSL is a genuine Linux kernel. But, the kernel is not the same as the OS. For example, Android is not Linux, even though both run the Linux kernel. WSL2 still largely relies on emulation.
I genuinely can't really decide right now whether I agree that the analogy was misleading. Seeing it as a WSL1 reference, sure.
WSL1 and Wine were much closer, technically, that's for sure. But does it make the analog fail, if one moves from a library layer that maps syscalls from one to the syscalls of the other, into running the core kernel in a VM, with that VM'd kernel talking to the host kernel via hypervisor services? Considering that all the userspace support libraries and services are still emulated, provided by custom code designed for exactly this purpose?
(In other words, if you do see it as misleading, I have no counterargument; I just am not certain if the differences are large enough to call the analog misleading. But, as usual, I am often wrong anyway.)
I was honestly surprised you could have missed WSL2!
Like I said, I don't personally use Windows at all, and although I had heard that a new version of WSL had come out a year or two back (had to check; WSL2 was announced in May 2019), I haven't had any reason to check what the differences were. The reports of incompatibilities I've heard about (nginx config and getaddrinfo() immediately come to mind) didn't really specify version either (they just say WSL, not WSL1/WSL2), and the same seem to still be an issue a year later.
The move in WSL2 for running a Linux kernel, does eliminate all kernel incompatibilities, so I do wholeheartedly agree that it is a leap forwards, a good thing. I was positively surprised to find out it was implemented that way!
But, the compatibility problems still exist. If you run the kernel in a VM, why not the entire OS? Modifying an accelerated Xorg server to use the Windows graphics subsystem should be less work than all this library and service level stuff, methinks (so that the VM'd applications would appear just like native Windows applications, perhaps with trivial native Windows process handles/placeholders/agents for Windows interprocess comms). That's what the existing X11 clients for Windows do for remote X11 connections, already.
If I wanted to run Windows stuff, I would definitely use a VM, instead of relying on Wine. I've done both, and the VM is more powerful, and does not really have any of the compatibility issues Wine has. (Plus, checkpointing: you can experiment with stuff, even install software you may wish to get completely rid of. Instead of uninstalling, reverting the VM to a previous checkpoint reverts everything. I can warmly recommend this, be it with Linux, Windows, or any other OS.)