I'm gonna take the contrary view - you don't have the source code for Windows kernel functions, so you can't see the comments, and even if you did, you wouldn't

I'm gonna take the contrary view - you don't have the source code for Windows kernel functions, so you can't see the comments, and even if you did, you wouldn't be able to click links to internal tickets. These smell exactly like specific workarounds for specific real-world issues where, for whatever reason, the documentation doesn't match reality. I've written lots of code where I write a two-paragraph comment in front of a one-line hack explaining why I'm doing something weird for now and why we hope to be able to clean up the code in five years - and that's just for legacy internal services, not weird CPU bugs. If you don't have the backstory and you just have the disassembled code, of course it will be "not at all obvious what problem Microsoft was trying to solve." A VMM on an NX-capable CPU that doesn't support NX doesn't seem like something that's worth MS supporting. I'm going to guess they talked about it internally, and decided that whatever they needed to fix was worth the tradeoff. Maybe there's one CPU where NX is in fact supported but for whatever reason it's missing in CPUID, and you've never seen that CPU. Also, honestly, a VMM that doesn't support NX sounds remarkably like malware, if you run into it in production and not on the system of a hobbyist writing their own VMM, and failing hard when you know the CPU you're on supports NX and you know that CPUID is lying to you is an entirely reasonable decision. Similarly, re skipping force-enable on 32-bit SSE2 CPUs - there's probably one CPU where the force-enable codepath causes some subtle problems, and this is the fastest/easiest way to identify that CPU, and they're not terribly concerned about accidentally missing some other cases. And again, you neither have the comments nor the `git blame` (or whatever MS uses) of that code nor the internal trouble ticket where someone spent weeks chasing down an elusive CPU bug. Of course it makes no sense to you. And if there is some real problem behind these two cases, it's hardly true that "the original issue is long gone" - Windows has very long support cycles. This isn't a "problem in the IT industry," it's the reality of the game. If you want your code to work on real-world machines and you want real-world customers to pay your real-world salary, you have to write code for the world as it actually is, not as you wish it would be.