These efforts are always to celebrate, however they always end up with leaky abstractions.
Just like on the other way around one needs to be aware of Objective-C for success, or .NET/COM on Windows.
You get (1) access to JVM APIs as normal on Android, and (2) Fairly full-featured interop with ObjC, Swift and C APIs elsewhere, and (3) A pleasant language with excellent IDE support in IntelliJ.
The `expect fun` / `actual fun` stubbing for different platforms also works in a fairly low-drama way. You can also share UI with Compose Multiplatform (less mature), or just write native views.
The downside (of course) is that non-JVM targets like iOS can't use the JVM ecosystem, and most of the Kotlin ecosystem assumes Kotlin/JVM. This is slowly changing though, and isn't a structural flaw.
Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.
I agree regarding Gradle, thankfully the time I used to do Android native development is behind me, even if I keep up with Google IO sessions, and ADP Podcast.
How is Kotlin Native maturity nowadays?
There are things you might expect to be able to do trivially (e.g. formatting a timestamp into a date string) had no off-the-shelf approach last time I tried. You'd need to roll your own, or pull in an existing non-kotlin library, e.g. something from C.
I think a lot of issues stem from existing APIs being designed around Java types that will never be available without the JVM.
Thus you can do anything Metal with Objective-C and zero Swift.
Also, writing drivers, even in userspace is still mostly C++.
Going on a tangent, even if Swift isn't everywhere still, I would like that Microsoft would be half as serious as Apple, regarding .NET use on Windows, however they aren't even serious with C++.