Intel did. Obviously there is more to it than just setting a different target and hitting compile but it's also not a ridiculous question because of that measure alone. It'd require enabling reduced security mode to load kexts or a custom kernel as well as a good amount of additional code for interfacing it with the macOS kernel interfaces but the majority of the code would be reused. Not trivial by any measure but also not an unreasonable approach in terms of total effort to get a working driver.
I'd be very surprised if anyone was interested in doing all that work given the security limitations and ability to just use Linux.
Edit: I forgot Metal is actually a userspace driver, you don't need to mess with the kernel side... though I can't remember if you still need to lower security to poke the right areas.
intel's linux driver is completely different from the windows driver. it also has been open since the start (well, since the start of the rewrite in 2010 or something) actually before AMD did theirs.
If you look the other way around (which is more relevant anyways), you can compile Mesa for Windows. However I'm pretty sure only the software renderer is available because Mesa is not capable of interfacing with the Windows kernel driver, as all the other drivers are coupled with Linux driver interfaces, iirc. (At least I'm quite certain this is the case for AMD.)
I'm also quite certain the proprietary NVIDIA driver shares a ton of code between Windows and Linux.
To add on, just because it's cool, there is a 3rd category in play with Mesa of layered drivers. Microsoft worked on and officially supports running OpenCL and OpenGL on devices which only have a DX12 driver via Mesa this fashion. Still all user space of course but not software rendering. More akin to MoltenVK from the blog post, except fully supported and maintained by the OS provider.
