Installed 3.11.0a3 was built Dec  8 2021, 22:56:33.  My corresponding repository build is a bit older than that.  Rebuilding now I get
  fileutils.c
..\Python\fileutils.c(2132): error C2065: 'PATHCCH_FORCE_ENABLE_LONG_NAME_PROCE
SS': undeclared identifier [f:\dev\3x\PCbuild\_freeze_module.vcxproj]

I have likely seen this before today but mistook the error message for a warning and did not check the respository build date.  3.9 and 3.10 just update normally, so unique to 3.11 and apparently new freeze changes.

The flag is not for Win8.1 and available starting in Win10 1703 with v10.0.15021 SDK.

Good catch. We still support 8.1 for this release, so that flag will have to be taken out (and hopefully people won't be impacted by long path names here).

With just PATHCCH_ALLOW_LONG_PATHS, PathCchCombineEx() returns a long path as a normal path (i.e. not a \\?\ extended path) if long-path support is enabled for the current process. Otherwise, if long-path support isn't enabled or available, as is always the case in Windows 8.1, then PATHCCH_ALLOW_LONG_PATHS makes PathCchCombineEx() return a long path as an extended path. In most cases, extended paths work fine. A common exception is that extended paths aren't supported for the working directory.

In Windows 10+, PATHCCH_FORCE_ENABLE_LONG_NAME_PROCESS forces PathCchCombineEx() to always return a long path as a normal path, even if long-path support is disabled for the current process. For most cases, this option pretty much guarantees that long paths will cause immediate failures if long-path support is disabled for the current process. In some cases one might want an immediate failure, instead of messing around with extended paths that might fail in some obscure, buggy way. Also, for pure path manipulation one may not care whether the current process can access the path without the \\?\ prefix.

Let me be clearer. This bug prevents me from building main (3.11) to test anything with a proper up-to-date 3.11 binary.  So to me this is highest priority.  Is this just my machine or every Windows system?  How are CI and buildbots rebuilding and running?  Is there some workaround I need to add?  Use newer VC (and change devguide)?

Only a newer WinSDK, which is not in any way a significant change to the resulting build and so isn't part of the "spec" as it were.

But we'll remove the use of this flag once someone has the time to make a PR.

(Remember to add the RM when you declare something a release blocker or the release may not be blocked.)

Terry, it's just a simple bug that slipped by. The PATHCCH_OPTIONS enum in the SDK header "PathCch.h" unconditionally defines all of the options. So there's no compiler error when building with a newer version of the SDK, even though we define _WIN32_WINNT to 0x602 (Windows 8).

New changeset d81182b8ec3b1593daf241d44757a9fa68fd14cc by Steve Dower in branch 'main':
bpo-46217: Revert use of Windows constant that is newer than what we support (GH-30473)
https://github.com/python/cpython/commit/d81182b8ec3b1593daf241d44757a9fa68fd14cc

Thank you.  Compiles without even any warnings.  Tests also all pass.