After packaging and C API WG discussions, I have another possible take on this: add abi3t as a new variant of a stable ABI, so that you can still build cp3.15-abi3 (non-free-threaded only) extensions. Defining both Py_GIL_DISABLED and Py_LIMITED_API would turn on the API limitations (opaque PyObject) and enable building against abi3t.
What this would change is “just” how things are named and enabled, but, perhaps it’s a better way to think about this. What do you think?
Preview: pep-previews–4747.org.readthedocs.build/pep-0803/
PR/diff: peps#4747