Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years.
Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
I typo'd that - it should be
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not).
What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has.
Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.