More powerful. Java threads are objects with a standard API for managing them, and you can do things like await concurrent work without rolling your own command protocol using channel pairs and hoping some goroutine out there might still be answering. A JMX client can even show them in a GUI.
This makes the same concept radically cheaper by not involving the kernel, which is great because Java hasn't had green threads for a long time, and doing everything async in small worker pools worked but has admittedly been pretty painful.
Coroutines in Kotlin are only a compiler trick, and are stackless. Go and Java's are stackful, reifed: small stack chunks are moved in and out of the heap to the carrier stack.
This means you get an actual meaningful stacktrace when debugging, and not something stemming from a mysterious event-loop thread.
In Java you could save your coroutine state to disk, and wake it up later in theory.
----
EDIT: This being said, I'm 99% sure Kotlin is going to pass Loom's goodness onto their developers when it's available, probably reusing the existing coroutine API.
Kotlin is placing themselves into a corner by trying to go everywhere and married Android.
So for every JVM/Java feature post Java 6 that gets introduced, they will have the dilemma of how to integrate them into a way that keeps language semantics across compilation targets, having multiple solutions to the same problem (Kotlin's one and what each platform later introduced), or just expose them via KMM and leave the #ifdef burden to the community.
That is why platform languages always carry the trophy, even if they are the turtle most of the time.
Well, so far that hasn't been an issue. Kotlin is a pragmatic language. The differences that currently exist can be addressed just with an annotation here or there. Also, Kotlin's features are designed whilst paying careful attention to what the Java guys are doing. Look at how records have played out. You can use JVM records from Kotlin transparently, you can create them by just adding an annotation (not that there's much point in doing so, as records are mostly a labour saving device that Kotlin already had).
Value types are perhaps a better example. Kotlin has them already with nearly identical semantics to Valhalla, but without the ability for them to have more than one field due to the need for erasure. Once Valhalla arrives, Kotlin can simply remove that restriction when targeting the JVM, perhaps add another annotation or compiler flag to say "make this a real Java value type". No language changes needed beyond that.
Kotlin is semantically so close to Java already that they aren't really growing apart, they're growing together. It works well enough to justify its usage, for me.
It sure is a dilemma. Java is catching up. When (if) Java introduces null-safety, Kotlin will loose much of its lustre, at least to me.
Virtual threads are superior to coroutines, which are still a pain in the ass in Kotlin, cause issues with mocking and you can't even evaluate them in the repl.
This makes the same concept radically cheaper by not involving the kernel, which is great because Java hasn't had green threads for a long time, and doing everything async in small worker pools worked but has admittedly been pretty painful.