Free user space for non-graphics drivers

Using DRM sounds like a lot of extra work for little benefit. The user-mode components which are being ported from Windows-only to cross-platform would have to support both DRM and D3DKMT kernel APIs, which I guess will have a lot of subtle differences and probably some major differences as they evolve and new GPU features are supported in one but not the other; then the Windows side would need to translate DRM back into D3DKMT. By using D3DKMT throughout, it's a simpler and much less bug-prone task of just proxying commands between the two kernels and recompiling the existing user-mode components for Linux with minimal API changes.

One of the major use cases seems to be CUDA (e.g. for developing and testing CUDA applications on Windows with WSL, before deploying to a Linux cloud), which is only supported on Linux by the proprietary NVIDIA drivers, so Mesa is irrelevant there. For 3D graphics, I assume there's normally some tight integration between user-mode and kernel-mode drivers, and the real kernel-mode driver (in the Windows kernel) is going to be the proprietary NVIDIA/AMD/Intel one, so you'll need the matching proprietary user-mode driver on Linux - you wouldn't be able to use Nouveau with it even if they all supported DRM.

D3D12 support on WSL doesn't sound directly useful for applications, because WSL seems like a development platform rather than a deployment platform, so games on Windows will use the native D3D12 API and games on native Linux can't use D3D12 at all (or at least Microsoft hasn't announced any plans for that yet). But D3D12 support means Microsoft can port their OpenGL-to-D3D12 translation layer (https://devblogs.microsoft.com/directx/in-the-works-openc...) from Windows to Linux with little extra effort, meaning OpenGL-based applications can be developed on WSL then deployed on Linux. (Apparently that translation layer does use the higher-level parts of Mesa, with a driver that talks to libd3d12 instead of libdrm.)