Nothing of the sort from what I've seen.

Windows 7 also wasn't that good either kernel wise. It did bring in some changes Microsoft started with Longhorn, and they definitely patched a lot of holes between Vista and 7, but they never really got time to properly iterate after breaking down their internal silos. In 2018, that kernel looks absolutely ancient and is holding back performance on modern machines. Microsoft finally cut some legacy, and stopped trying to patch ancient kernels to take advantage of modern processors. Their only other viable choice in my mind was to hire a second kernel team, and let them focus on legacy improvements while allowing the main team to keep pushing Win10/Server2016 forward. And yes, please let them keep going, the work they did to enable WSL is amazing and useful, as well as using NVMe drives properly.

Back during the Vista development for example, the team building the new start menu had to wait 3 months to get new code from the kernel team to support them. If it was buggy, another 3 months would go by before the first attempted fix would land from the kernel team. From what I understand, this improved a little for some teams with 7 development, but not enough.

Windows 8/8.1 pushed the kernel more, but most of the efforts there went into the tablet stuff and not making the kernel/user swaps more efficient. At the time, that decision made sense for sure.

Windows 10 now, it's on a good path. Microsoft has the ability to patch the kernel in major ways on consumer machines every 6 months. Compare that to internal teams not getting updates every 3 months 10 years ago. The amount of effort MS had to go through to drag Windows into modern development practices is impressive, and they have my respect for enduring it while their users spin conspiracy theories

Ok, how's the rest of the industry doing on kernel updates? Well, Apple's been able to ship updates to it to customers reliably, since, umm, March 2001 when OS X launched. Linux, it is the kernel, and is hyper optimized to deliver updates. We all benefitted from that setup with prior community kernel patches and Mr Lord's Hijack work to unify them. To tie this back to Windows 7 kernel example, I highly doubt it's worth the effort to try and build a new empeg-car that can include current Hijack releases seamlessly, and instead start fresh with todays Linux kernels. I remember when kernel 2.2 was new and shiny, and a 2.4 future was opening up. Now those numbers seem like ancient memories, and ancient ways of doing things