☝️Coming back to the multithreading issue... is it true that you cannot access Kotlin native objects from another thread than the owning thread?

Yes. Their is a very different concurrent shared memory model for kotlin/native than java. Basically there is no shared mutable memory.

Thanks for confirming this. Is there any rationale for this architectural decision? I'm wondering if it's a opinionated design choice or if it's related to some specific implementation detail, like GC. It seems at odds with the concept of allowing portability between platforms and flexibility to integrate with native libraries.

I’d recommend reading https://github.com/JetBrains/kotlin-native/blob/master/CONCURRENCY.md as it covers important aspects of vision on concurrency in Kotlin/Native. We do not support shared heap, as believe that it is not really reliable programming model. Also this memory management model allows pauseless execution + cycle collector, unavailable on other platforms. However, in interop scenarios, where there are existing APIs with different view on how concurrency to be done, we will implement some helper functionality, allowing easier debugging and implementing callbacks, executed on other threads. See this example https://github.com/JetBrains/kotlin-native/tree/master/samples/globalState for various solution of the global state problem.