Hopefully, at this point, you see where I’m going with this. What I’ve concluded, based on experience, is that positioning your project as an alternative implementation of something is a losing proposition. It doesn’t matter how smart you are. It doesn’t matter how hard you work. The problem is, when you build an alternative implementation, you’ve made yourself subject to the whims of the canonical implementation. They have control over the direction of the project, and all you can do is try to keep up. In the case of JITted implementations of traditionally interpreted languages, there’s a bit of a weird dynamic, because it’s much faster to implement new features in an interpreter. The implementers of the canonical implementation may see you as competition they are trying to outrun. You may be stuck trying to ice skate uphill.
This is surely true in Python or Lua, but I believe it might not necessarily be the case for Java (where there is a specification, and enough effort by the industry to create alternative implementations). But I agree in general, unless you have something unique (like Android support, despite Dalvik being stuck on Java 8 for ages), which both IronPython and Jython didn’t have — I guess there is no general need for accessing the .NET and JVM runtimes from dynamic languages.