If you read the replies by Dave Airlie and Daniel Vetter, it seems somewhat likely that upstream won't accept it. Perhaps that's just initial skepticism that will evaporate after more discussion, but perhaps not.

Frankly this does just seem like MS wanting to reduce their maintenance burden on what they expect will be a very important part of their WSL offering on Windows. There's nothing inherently wrong with that desire, but the people on the other side need to weigh their maintenance burden[0] with what benefit this will have to the Linux community as a whole, which at first blush seems minimal. Especially considering that the userland pieces that talk to this driver aren't open-source.

There's also the question of whether or not you believe WSL as a whole is good or bad for Linux. If there are people who would run a Linux desktop for development who then decide not to because WSL exists, perhaps that's a bad outcome. If you have people writing more DirectX GPGPU code who would otherwise write to a standard interface like OpenCL, perhaps that's a bad outcome (to be fair, there's also a lot of CUDA out there, which is similarly problematic). Is this the start of MS going back to their "Embrace, Extend, Extinguish" playbook, or is that just a paranoid fear? They've definitely been embracing Linux, and enabling people to write DX12 GPGPU code that targets a Linux environment but will only run under WSL on a Windows install does feel like "extend".

I'm not sure where I personally stand on this issue as I haven't done my research, but I think they're interesting questions to ask.

If this gets rejected, of course it doesn't stop MS from doing any of these things, but it does make it harder for them to maintain their extensions to Linux.

[0] Airlie is even concerned that just by looking at the code, he or other DRI developers could run into future IP derived-works trouble when designing future Linux graphics interfaces.