The problem with the way JXcore did the SpiderMonkey port is their extensive use of C++ macros - not unlike NAN for Node.js. This makes the code hard to debug and maintain. The Microsoft Chakra Node port is more elegant because they've mimicked the V8 C++ API making it much more likely that it will be merged into Node.js and IO.js. In time I suspect Mozilla and other javascript engines will make V8-compatible API shims similar to what Microsoft did:
The Python GIL problem could been solved in Python3 by just moving all global interpreter instance variables into a single struct and changing the C API to take a pointer to this interpreter struct as the first argument in all C API functions. No thread local variable hacks need be used and all interpreter instances could have been completely independent of each other, allowing for seamless and efficient share-nothing multi-threading. Python3 was not intended to be 100% compatible with Python2 anyway, so it was a perfect opportunity to fix this long standing design bug. But this opportunity was lost.
Strangely, the Google V8 team repeated Python's API design error and also relies on global interpreter variables and thread-local variables to swap interpreter contexts, or "isolates" in V8-speak. Although my understanding is that the V8 team recognizes the problem and are (slowly) addressing it and changing their APIs accordingly with each successive release.
https://github.com/Microsoft/node/tree/ch0.12.2/deps/chakras...