[rnentjes]

There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific.

This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).

[pjmlp]

Co-routines aren't the same as Loom, as they require explicitly code and thus might not interop cleanly with the new Loom thread semantics.

Does Kotlin/Native support multi field value classes?

Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to.

However then one begs the question why use the language at all, when having to write the same stuff multiple times.

I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.

[rnentjes]

Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).