It's closer to the way vendors like Qualcomm shipped GPU drivers for ARM Linux until relatively recently, where they would ship a patched kernel with a DRM driver, and then a closed source userspace .so blob that you had to rely on, on top of that, which implemented the shader compiler, pipeline, etc. This is basically that. Except it's a virtual machine, so it's also kind of like how VMware Workstation does graphics acceleration.

The main difference here from the ARM world is that Microsoft seems to have invested dev work in upstream Mesa so that Mesa actually implements the nitty gritty parts of the spec on the Linux side, and then translates it all to underlying D3D12 host calls for you. This is conceptually similar to VirGL, which is basically the same thing but for OpenGL inside QEMU. If anything Microsoft seems to have taken a less arduous approach to this by going to upstream first to Mesa. The other thing here is that Microsoft is using a patched kernel that hasn't been merged upstream; but then again Asahi Linux is in the same boat, and they work upstream in Mesa now, too. And Mesa isn't just limited to Linux, of course, and can be used in userspace in theory a lot of places.

If you have some weird desire to use DirectX APIs on Linux, you can already do that in many ways with subprojects of Wine and Proton such as d3dvk. It's a well known API with a well known ABI so it's not like this is impossible. You can already run many Windows programs through Wine, so unless this hypothetical Windows/Linux monstrosity thing is going wildly out of its way to be WSL only through active hostility, it's not like there's some magical API that can't be emulated in most of these cases.