Given the alternative of using sysconfig and PEP 780's proposed sys.abi_features, I'm not sure this is worth it. Adding a DeprecationWarning still imposes a cost on users because now they have to change their code to avoid or suppress the warning. The benefit of such a change would still be years in the future, at which point I'd hope that sys.abi_features would be a better alternative.

I don't feel particularly strongly about this, so if @zooba thinks this is a good approach, then it's fine with me.

The benefit of such a change would still be years in the future, at which point I'd hope that sys.abi_features would be a better alternative.

The sys.abi_features alternative does not replace the incoming change of sys.abiflags and vice versa. Both can benefit the community independently.

The recent update of the action/setup-python adds 3.13t support (release note). I changed the code to determine PYTHON_TAG which is used in the artifact name (e.g., coverage-${{ env.PYTHON_TAG }}-${{ runner.os }}.xml) in https://github.com/metaopt/optree/pull/198/files.

export PYTHON_TAG="$(
  echo 'import sys, sysconfig; print(
    "{0.name[0]}p{1.major}{1.minor}{2}".format(
      sys.implementation,
      sys.version_info,
      getattr(sys, "abiflags", "t" if sysconfig.get_config_var("Py_GIL_DISABLED") else ""),
    ).lower(),
  )' | ${{ env.PYTHON }} -
)"

This would benefit from a valid sys.abiflags on all platforms.

The incoming sys.abi_features would be useful. But in scripting and CIs, a good sys.abiflags can make the inline code shorter and easier to maintain.