WSL2 is actually the third iteration of this technology, not the second, and I believe has the same original goal and they've dedicated a large amount of engineering effort to that goal.
Here's my case:
Windows 10 Mobile had "Project Astoria", which involved working with app developers to port apps to Windows Phone. This involved library support and translation layers to enable APKs to run on Windows.
WSL1 abandoned the approach of requiring developers to modify apps, and used "pico processes" with kernel driver and Windows kernel's support for alternative subsystems to Win32 to map Linux syscalls to Windows equivalents. This enabled binary compatibility for most apps, but fell short.
WSL2 switched to the lightweight Hyper-V integration (now using the host compute system APIs to manage lightweight containers/VMs) but added deep driver integration with graphics to enable machine learning and hardware accelerated graphic workloads to work within Linux using vGPU drivers and RAIL respectively. And soon VAIL, to enable full fidelity graphical applications (i.e.: Android apps) to run on Windows without compromise.
That's a lot of engineering time on 3 high complexity projects over a span of at least 6 years, publicly.
Link to a talk on X11/Wayland and VAIL: https://xdc2020.x.org/event/9/contributions/611/attachments/...
I don't think VAIL has shipped yet, and getting that working correctly and securely, as it involves sharing memory between the WSL2 VM with a Linux kernel and the host Windows kernel, seems to me the most likely blocking issue for why they haven't yet released Android app support on Windows. See this comment on the readme of the WSLg repo:
> Please note that for the first release of WSLg, vGPU interops with the Weston compositor through system memory. If running on a discrete GPU, this effectively means that the rendered data is copied from VRAM to system memory before being presented to the compositor within WSLg, and uploaded onto the GPU again on the Windows side.
As for originally being intended for Win32 apps, I do wonder if "Vail" and "VAIL" are different projects within the OS division. The Linux/X11/Wayland and vGPU interop part of VAIL requires different expertise and deep knowledge of the Linux graphical stack.
And for the other parts, the interop bits are new, but the deck from when the WSL2 devs presented this specifically said it was a great solution because it was already being used for Azure Virtual Desktop (hosted Windows VMs).
The difference is not whether GPU applications do or do not work. They work with both. The difference is, do they work with zero copying via shared memory between the Windows host and the WSL virtual machine?
RAIL enabled graphical applications - including those that use the GPU - to be presented as windows on the Windows desktop. But it involves extra latency on the order of several to tens of frames, depending on how expensive the framebuffer copying and synchronization steps are.
VAIL enables performance (and input lag) that is on par with running Linux natively.
In general the experience is worse than using a real macos app but it as terrible than running in Web browser/electron (e.g. Slack, Spotify), or a macOS app that looks like it was written under duress by someone who didn’t give a shit (e.g. WhatsApp)
Unfortunately, Google's anticompetitive moves with SafetyNet will ensure that many Android apps will only run on Google-blessed hardware and software platforms.
WSL 1 & 2 are amazingly innovative platforms, as is WINE. Microsoft has undoubtedly created untold value for developers and their shareholders with WSL. The anticompetitive limitations implemented in SafetyNet, however, serve to stifle such innovation, and prevent many Android apps from running on other platforms.
If there is a larger purpose around WSL, VS Code, and "MS <3 Linux" messaging, it is definitely this. They have really changed their reputation among developers.
However, I can't ignore that they've certainly created value for engineers that use Windows to develop software that runs on Linux, similar to the value created by WINE's developers. It's just a shame that similar value and innovation are stifled by the limitations set by Google's SafetyNet when it comes to running Android software on other platforms.
However, the goal wasn't to make "Linux" a first class citizen so much as to bring "non-Windows" developers underneath the mothership.
It's even beginning to affect the embedded world: https://www.nordicsemi.com/News/2021/10/Nordic-launches-nRF-...
... now if only the language servers it relies on could be anywhere near as polished :| rust-analyzer is a stunning example of what's possible with language services, gopls is only barely functional enough to be worth running.
At the scale of MS a "major" Windows feature can't be cheap, even if it looks simple.
Seriously, look at how difficult it is for them to port the old style control center or improve notepad.exe.