Right. It's exactly this sort of coupling between the runtime and extension modules that prompted me to adopt a very conservative design for the Emacs extension

Right. It's exactly this sort of coupling between the runtime and extension modules that prompted me to adopt a very conservative design for the Emacs extension module interface, which tries as hard as possible to isolate extension modules and abstract over VM implementation details. I didn't quite get as far as I wanted, since the module system still relies on conservative stack scanning to find C-extension GC tools (because everyone else wasn't sold on JNI-like explicit local references), but it's still much more tightly specified than the Python API. The Python extension API has another problem: it relies on FILE* and other assorted bits of the C runtime. That's mostly okay on POSIX-y systems where it's common for a whole process to share one C runtime, but on Windows, where different modules can come with different C runtime versions, this kind of leaking of objects across an interface boundary really hurts.