I really feel like the right approach for this kind of thing is something like emscripten, but not emscripten. It just doesn't make sense to duplicate the garbage collection (never mind that interactions between different GCs can be strange and unpredictable) and run a whole VM for it.
What we need is a similarly narrow target JS subset for dynamic languages where the outer GC is actually functional and lookup/inline cache kinds of optimizations can be performed on correctly generated code.
I like the idea, and it could work in many cases, but it's hard to make it truly universal. For example languages like Lua, Java and C# have finalizers, and JavaScript GCs do not, so you can't reuse the outer GC. Other possible issues are weak refs, etc.
So even if we duplicate by compiling another GC, we are enabling new types of GCing, it isn't an exact clone.
> It just doesn't make sense to duplicate the garbage collection
This is reinventing the wheel so that you have the ability to ensure the wheels you are using are actually round.
While there are potential performance benefits in using a provided-system, something like Garbage Collection is a pillar upon which most of the program rests. I wouldn't trust the behaviour of all of the existing implementations to seamlessly work the same way reliably. If you discover a flaw in the system, being able to fix it can allow you to continue working. That is much better than filing a bug-report and waiting for the development cycle to churn out a released fix.
If we're going to get into metaphor then I'd like to point out that running a garbage collector on top of another garbage collector is a bit like driving a car on a treadmill mounted on a truck. ;)
What we need is a similarly narrow target JS subset for dynamic languages where the outer GC is actually functional and lookup/inline cache kinds of optimizations can be performed on correctly generated code.