Doesn't Graal/Truffle address that pretty directly? It's a way to build language interpreters directly on top of the JVM that can JIT the interpreter as well as the code running on top of it.
Unfortunately not. Graal/Truffle solves the problem of making it easier to implement a language on the JVM. However, there is still some friction if your language has different GC semantics than the JVM. For example, you can make python on the JVM, but it is really hard to make the C interface for python work on the JVM. This is mainly due to the python memory model which, for worse, assumes that data in memory isn't moved by the GC. It allows for you to directly manipulate python objects in C code without fear of that data moving to a new location.
Javascript is much easier to do in the JVM because the language makes no assumptions on how memory is stored (AFAIK).
What languages have materially different GC semantics, other than Python on the cpython vm? (PyPy loses the fast collection at the end of scope for efficiency reasons)
Python is the key one you already mentioned - it has deterministic semantics and most other language do not.
Ruby also exposes parts of its GC, and allows it to be hooked by C extensions, so when I implemented it on top of the JVM I had to basically reimplement half of it in Java in order to implement those parts of the language.
Erlang's allocation pattern is markedly different than e.g. Java's, in no small part because it's completely impossible for an object to refer to a more recent allocation than itself. More generally, immutability-heavy language would have quite different needs than mutation-heavy ones.
Finalizers and resurrection is a big way that GCs can differ. There's also exotic reference types: Java has WeakReference, SoftReference, PhantomReference...
That's great if the language you're using has the same GC semantics as the language you're implementing, and a pretty major problem if it doesn't.