>[...] but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages
Not for me. Go's type system is too primitive, and Rust is maybe too low level if you don't need the advantages compared to languages with a GC. So a language like Kotlin with a better type system (than go) fits nicely in between the two (that might change if Rust get's a GC type). Especially since it will probably have (or has already?) better tooling considering that Jetbreains is behind it.
Funny enough, all commercial JDKs do support AOT compilation to native code, and Oracle is slowly adding support for it as well.
I find it's a fundamentally better language than both and so being able to write CLI tools and other smaller stuff in it would be nice while still being able to leverage Kotlin + JVM on the backend would also be nice.
Just wanted to point that out in case you didn't know that already.
Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.
I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.
My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.