>the scenarios that result in errors are totally different from the error scenarios in linux.
Not really. It's more like the Windows problems are a superset of the Linux problems. Most kernel panics are a result of bugs in drivers which happens just the same on Windows. Then you have all the ones based on Microsoft laziness, like getting the INACCESSIBLE_BOOT_DEVICE BSOD instead of the OS trying to load some more drivers if your disk controller died and you replaced it with a different model. And then you have the fallout of Microsoft's attempts to fix legacy software rampaging through kernel memory, which means all the legacy code that used to do that (including the ones that did something useful instead of causing a BSOD) will now just crash the application and break the legacy software, because Microsoft couldn't be bothered to get it right the first time.
> most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel.
The difference is that Unix-like operating systems have always discouraged that behavior so it happens a lot less often (and is a lot more suspicious), and if you have something that legitimately needs to go into the Linux kernel then it generally gets merged into the main tree. But not until you fix what problems the kernel maintainers identify, and then it gets maintained by the people who know what they're doing.
> the "compatibility layer" is actually far more nuanced than this
Sounds unnecessarily complicated and undesirable.
> NT was designed by the team that did VMS in a 3-month retreat to Hawaii.
NT was never the problem. That's like saying ReactOS will be good because it's designed by smart people. The "design" is already cribbed by what came before it and the box it now has to live in, which was set out by DOS and Windows 95. Microsoft now has to live with that legacy, why should the rest of us?