I think there is a problem with this approach. I understand the motivation for the change: not breaking source compatibility on GIL-enabled builds, as @steve.dower points out in capi-workgroup#92-comment. And I agree that that’s a good and probably necessary goal.
However, reusing Py_GIL_DISABLED to enable the new abi3t which will also support the GIL-enabled build and produce wheels tagged abi3.abi3t, will be cumbersome. If a package author makes source-level changes to support abi3t, then they can no longer build under a GIL-enabled 3.15 interpreter without disabling the Limited API completely. Which will require annoying fiddling with default build flags.
Related, testing with abi3t on a GIL-enabled interpreter, say in CI, would require building against a free-threaded interpreter, and then in a separate job install it for a GIL-enabled interpreter - not all that simple.
It seems more user-friendly for the “enable abi3t” to be a separate define from Py_GIL_DISABLED. It doesn’t really matter what it is, but I’d think not coupling it to implementation details (like the -DPy_OPAQUE_PYOBJECT you had) but rather a separate knob (e.g., -DPy_LIMITED_API_TARGET_ABI3T).
Note: in the above I am assuming that it’s a bad idea to define Py_GIL_DISABLED when building under a GIL-enabled interpreter, because that define controls a lot of other things, both inside and outside CPython. I hope you didn’t have that in mind?
A separate knob is also not completely free, but much easier to deal with, and until that’s implemented in build systems/backends, any package author can add the extra define themselves pretty easily.