However, I didn't think that's how Windows versions were reported to applications, I thought they used GetVersion/GetVersionEx (or nowadays one of the new APIs, now that GetVersion has been deprecated and emulated with 8.1), which always has reported the kernel numeric version (or an emulated numeric version, but never the marketing version), rather than any API to get a textual version (or, rather, the internal code to display a textual version was either hardcoded or itself used GetVersion and a lookup table). And GetVersion was the documented way to get the version since at least Windows 3.0.
Basically, if GetVersionEx weren't deprecated, software would see PlatformID == 2 (which means NT, PlatformID == 1 means the DOS-based lineage), MajorVersion == 6, MinorVersion == 4, on whatever they had called the new version of Windows. (What it'll actually see, normally, is MinorVersion = 2, they're basically always going to report Windows 8.0 from here on out, unless a newer version is in the manifest. There's other ways they want software to detect a Windows version now.)
If they were checking for Win9x, they'd want PlatformID == 1, MajorVersion == 4. (And, there was quite a lot of software that would have worked perfectly fine on Windows 2000 and XP, that broke because it didn't work on NT 4, and was checking PlatformID... this is a large reason why the compatibility settings existed, so you could have Windows return that it was a different version (as far back as Windows 2000) to the application.)