Seems easier for us to just check this on our side than to expect users to get it right?

And isn't the legacy value 1 rather than 3?

Well, users should use PyABIInfo_DEFAULT_ABI_VERSION or PyABIInfo_VAR -- those are our side too.
I prefer the data to be simpler, but if you want, we can keep the exception in.

The legacy value is 3. (Not that it matters that much; it's always compared to a Python version.)

We're still planning to get rid of these options once FT is merged, right? Maybe we ought to use abiflags here (i.e. a string) instead, for future extensibility? This isn't going to be checked anywhere that it needs to be bitflags.

How would you encode being compatible with both GIL and FT?

IMO, we can remove them when there are no GIL-only extensions around any more. That would be a lot of time after FT is the only option.

What are all of these warnings about? Does _Py_PACK_VERSION do something funky?

No idea. I'll need to check on a Windows box.

I wasn't able to figure it out. Something seems to be compiling modsupport.h outside of Python.h -- that is, without pymacro.h being included first: I get an error if I add this before the line:

#ifndef Py_PYMACRO_H
#error this should not happen
#endif

The error is currently quite impenetrable to me:

 ResourceCompile:
 C:\Program Files (x86)\Windows Kits10円\bin10円.0.26100.0\x86\rc.exe /D "ORIGINAL_FILENAME=\\\"python315_d.dll\\\"" /D FIELD3=100 /D _DEBUG /l"0x0409" /IC:\Users\encukou\dev\cpython\PC /IC:\Users\encu 
 kou\dev\cpython\Include /IC:\Users\encukou\dev\cpython\PCbuild\obj315円amd64_Debug\pythoncore\ /nologo /fo"C:\Users\encukou\dev\cpython\PCbuild\obj315円amd64_Debug\pythoncore\python_nt.res" ..\PC\pyth 
 on_nt.rc
 3>C:\Users\encukou\dev\cpython\Include\modsupport.h(98): error RC2188: C:\Users\encukou\dev\cpython\PCbuild\obj315円amd64_Debug\pythoncore\RCa08340(52) : fatal error RC1116: RC terminating after preproce
 ssor errors [C:\Users\encukou\dev\cpython\PCbuild\pythoncore.vcxproj]
 3>Done Building Project "C:\Users\encukou\dev\cpython\PCbuild\pythoncore.vcxproj" (Build target(s)) -- FAILED.

Ah, it's being referenced from PC\python_ver_rc.h, which runs under the resource compiler rather than the C compiler. It's pretty much entirely compatible, but occasionally has some obscure/subtle differences.

I think it's just bypassing a lot of unnecessary includes here, assuming that modsupport.h stands alone. If that's not true, then the header needs updating and whatever constant it's referencing will have to move elsewhere.

I switched this PR to use 0x030f0000; I plan to switch to _Py_PACK_VERSION(3, 15) in a follow-up PR.