I can go fetch similar comments from online archives from every guest language on the JVM, CLR, WebBrowser.

The guest languages require additional tooling, duplicated libraries (because just using the platform libs isn't idiomatic, whatever), and then as the platform moves on the seamless FFI stops being so seamless, specially when the guest language decides being a guest language in just one platform isn't enough for its life achievements.

Eventually the platform language acquires enough features, which remove the spotlight from the guest languages, and projects start to migrate back, ah then the "Why X in Y" blog posts, with reference to "Why Y in X" start to appear.

As for Arrow, if you want Haskell, it already exists.

Historically, I agree. But this time really is different. No other JVM language has backing or buy-in even remotely comparable to Kotlin, and it's more seamless than any other JVM language I've experienced.

For what it's worth, in case I come off as a die-hard Kotlin fan, I'm really not. I strongly disagree with many choices the designers make with Kotlin - there's too many to list, but the common theme is basically, as good as Kotlin is at discouraging the worst of Java, it still caters far too much to nonsensical Java practices IMO.

I doubt it, Kotlin has decided to be Android's darling, thus buying into Android Team's bias against modern Java (and JVM features) support, while at the same time JetBrains is trying to turn Kotlin into its own eco-system stretching into JavaScript, a native implementation which requires specific code patterns for KMM libraries, and Kotlin specific libraries.

Eventually Kotlin needs to decide which master it wants to follow.

Java only needs to bother with keep being Java, everything else in terms of OS and AOT/JIT/GC support is just a matter of picking the respective implementation with zero code changes.