This. And there's no evidence that these changes correspond to exploitable security vulnerabilities. If you look at the slides, what they're actually complaining about is that certain OS code paths have been updated to use intsafe.h/strsafe.h functions in Windows 8, but not in Windows 7. Because intsafe/strsafe are used to help avoid overflow vulnerabilities, the conclusion the article draws is that these must be actual vulnerabilities, which are being fixed in Windows 8 without being ported to Windows 7.

It's worth noting that the entire presentation that the article is based on is an advertisement for their DiffRay diffing tool, so they have some incentive to overstate things. It's entirely possible that the changes that they're pointing out as "fixing potential 0-days in 8 but not 7" are actually just moving a couple of bounds checks from ad-hoc implementations in the functions themselves to the standardized common intsafe calls. Or it could be that there is already correct bounds enforcement elsewhere, and these checks are just added for redundancy, or to make function-local static analysis a little bit cleaner. I honestly don't know, but there are enough plausible benign explanations that the alternative of "Microsoft is deliberately exposing its largest set of customers to vulnerabilities" seems kind of absurd. Bring me the extraordinary evidence for this claim.

Disclosure: I'm a dev on the Windows team. I don't have any specific knowledge of this, and I'm not writing this in any official or compensated capacity.