Yes, but would it still be worth it? That's the question that maintainers should ask themselves. Pretty hard to do much of anything without uproar of some sort at this point, even the most recent no-GIL proposal had people complaining about it. Just use the version you're happy with and live your life.

> Then I guess the related question is: is this safe to use with Python implementations other than the main one (CPython)?

Absolutely not.

> For example, PyPy or Nuitka, neither of which use byte code (or at least I don't think so)?

pypy absolutely uses bytecode. Though not necessarily cpython's bytecode (although I'd expect they have at least a bridge for cpython compatibility).

Jitting straight from the source is pretty rare and tends to be avoided: it means either you don't have a baseline interpreter, or that you're repeating the work of the interpreter in your JIT, or possibly that you're interpreting and jitting from the AST.

The former is what Chrome did at the start, it had a baseline compiler and an optimising compiler, which was pretty weird. After a while a baseline interpreter (ignition) was introduced, and the bytecode it generated got fed into the optimising compiler. Its timeline was a bit odd because rather than building a bytecode interpreter then building a jit for that bytecode they actually started with a bytecode-based JIT (turbofan) then figured they could interpret the bytecode directly instead of having to deal with (and patch) code from the baseline compiler, so the interpreter (ignition) grew from the effort of building a new compiler, rather than the compiler being built for the interpreter.

As for AST interpretation I know it's pretty common for teaching / learning but I don't know if there's any system actually doing it for real "in production", the amount of pointer chasing seems like it'd be ridiculously inefficient.

Same diff, the entire thing is an implementation detail of cpython and deeply tied to that VM.