Apologies for not noticing this at the time.

This is incorrect. The _co_instrumentation_version being greater than zero does not indicate whether a code object is instrumented.
It may suggest that it was instrumented at some point, although that may not remain true.

The version number has no meaning at all, expect to the instrumentation system, and shouldn't be used to infer properties of the code object.

FWIW, this change only moved an existing hard-coded expression to a macro. I have no problems with any of it getting refactored to be more correct or better named. My motivation here is strictly to support building the 3.12 backport of my PyPI package. Replacing a macro is a lot easier than directly replacing a line of code in a file.

Maybe so, but it is still incorrect.
It was added originally here: 92ca90b#diff-f29800af0b7052514f5cc3d1a5858d704a8f0dee4c88788b741c00a0ff39f8d0R402

What are you guarding against, and why?

In that spot we are rejecting (for now) any code object that isn't completely basic. That includes ones that might have instrumentation.

Instrumentation is not a feature of the code object any more than specialization. It is how the interpreter does monitoring. If you marshal or copy a code object, the instrumentation is stripped.

In other words, checking for instrumentation is unnecessary here (or anyway else, in theory).

Even if it were necessary, _co_instrumentation_version does not indicate whether a code object is instrumented or not.
We would need a proper API to detect instrumentation (which would probably need to scan the code)

_PyCode_HAS_INSTRUMENTATION is misnamed and an attractive nuisance. Can we please remove it?

The same reasoning applies to executors, and _co_monitoring.
We can ignore _co_extras as well, as _PyInterpreterState_SetEvalFrameFunc is per-interpreter now.