Scala Native and GraalVM Native Image are projects with different goals, so I wouldn't say that one makes the other unnecessary.

Both projects aim to compile to native code, and have use-cases for projects where the JVM startup time is too high. However, one of the main goals of Native Image is to offer as much partial evaluation (PE) at compile-time as possible. Scala Native does also seem to do some PE, but my understanding is that it's less than what Native Image does. However, Scala Native has the advantage of working on a representation of the source code instead of the byte code, and may therefore be able to do certain Scala-specific optimizations that would be more difficult for Native Image.

I think different projects may find that either one or the other project may be more suitable to their needs, so I think both projects can coexist.

> However, one of the main goals of Native Image is to offer as much partial evaluation (PE) at compile-time as possible.

This is tangential, but I wonder if Native Image's focus on compile-time PE, and the overall design of GraalVM, would make it feasible to AOT-compile a sufficiently static subset of JavaScript to efficient native code. If so, that could influence my choice of language for new projects.

First AOT binaries are slower than JIT, there's nothing efficient about it, at least for high level languages. Second you can already make javascript binaries thanks to GraalJs. The biggest added value by far is the polyglotism/interop with the other language universes.