In my limited understanding, all PR #15951 does is set a compiler macro to allow use of Win API calls present on >=Win8 instead of >=Win7. If Win8-only calls are not used, then presumably it should still build and run on Windows 7, presumably with the flag flipped back to Win7. And if there are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC compiler will catch any instances of Win8-only calls at build time? Is this understanding correct?

If the latter is true, its very likely a lost cause. However, if the former is the case, then at least devs using Python 3.9+ on Windows 7 will be able to easily build their own versions with support, though that could change at any time. If the upside to supporting the latest Python versions on an EoL platform that is no longer receiving security updates but still has significant use is greater than the (seemingly pretty small) benefits of dropping support, then I imagine it would at least be conceivable to switch the flag back, though it probably is a lost cause now that a major version has been released without support and the buildbots have been presumably retired. At least third parties should be able to easily release patched versions, for now.

For those in the know, have there been a lot of reports/discontent surrounding the dropping of support in Py3.9, by anyone aware of that? 

However, I don't think it should be tied to the ESU date at all, as opposed to real-world usage of bleeding-edge Python on that version; ESU is a paid-only service for large corporate customers; if they're willing to pay through the nose for updates to their EoL OS and also need the latest bleeding-edge Python, surely they can fund the pittance required for maintenance or building it themselves.

All that said, I'll hold off on doing anything further until there's consensus. I'd think whatever we do it should be consistent, at least in the docs and installer; if dropping support in the code itself is more risk and pain than benefit, then that needn't be done.