That’s the idea, just like coroutines in Kotlin.
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.
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.
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.
PMD, SonarQube and nullable annotations have long sorted that problem in our Java projects.
Not a fan of any of those tools, tbh. Still better than nothing I suppose, but I'd rather use Kotlin in the meantime.
Right now there are 20 years of having null as default and turning it on just generates endless warnings.
So it is left for complete new projects where almost no third party libraries are being used, which right now is very little.
I also hope that C# 10 doesn't get !! for checked parameters, but it might already be too late.
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.
Just like those, it will slowly adopt whatever is more appealing from the guests and then carry on its merry way, while the other slowly lose their relevance while newcomers try yet again to challenge the place of the host language on the platform.