Dart/flutter of course predates a lot of this stuff. But the point is that Kotlin and Kotlin multiplatform are things that happened to Google that they ended up endorsing and embracing (to their credit).
When they were digging in with the Oracle lawsuit, their Android Java support fell behind a bit. And then Kotlin showed up as a drop in replacement and quickly became the default for a lot of Android development. It was so obviously nicer than Java 1.6 that many Android developers didn't bother waiting for kotlin 1.0 to be released even. Java support was eventually upgraded for Android but that took a while. Google made endorsing Kotlin official many years ago. Kotlin is now the preferred language for Android development. And while Java is still supported, using it is probably a mistake for new applications as Java API support increasingly an afterthought in both Android SDKs and the wider library ecosystem.
Google also pushed Flutter as a completely new way of doing UI and targeted it at a completely new OS (Fuchsia) that would replace Android. That never happened and Fuchsia is basically still around on life support but otherwise not going anywhere. Meanwhile, Flutter seems well liked by some but it's also a bit a weird techstack with its own language and compiler and fairly limited integration options. In short that whole techstack seems increasingly a bit of a dead end.
And crucially, Google has always pushed back on the notion of building any support for Kotlin around flutter, which was an obvious thing to start doing years ago. There are some weak arguments about native compilation here. But Java/kotlin were always compiled ahead of time on Android. So, I expect that the dominant arguments here were non technical and boil down to not invented here syndrome.
And now kotlin multiplatform (endorsed last year by Google) and compose multi platform are there. Compose multiplatform is interesting because it extends Google's own framework to other platforms (IOS, Web, Desktop). That has been an obvious thing to work on for a while but Google didn't want to go there because it had Flutter. But now Jetbrains has done it for them. The multiplatform support on IOS is getting quite nice. Native compilation, easy bindings between kotlin and swift code (both ways), etc.
It will be interesting to see if Google rallies behind compose multiplatform as well. IMHO they should and it's an opportunity to get a bit of control over IOS development and wrestle that away from Apple.
That usual Kotlin narrative keeps forgetting that Android Studio, Gradle, and Kotlin itself are built and depend on, Java based technologies, and there is no Kotlin without Java ecosystem, unless JetBrains ends up releasing a Kotlin Virtual Machine, and rewriting all the Android development stack on top of it.
Additionally, to prove this point even further, as the Java ecosystem keeps moving along happily, despite the anti-Java jabs typical among Android developers playing with Kotlin, ungrateful for its origins, the Android team was obligied to make ART upgradable via Play Store, and update its Java language support all the way up to Java 17 LTS, so that Android developers could still make use of Java libraries on Maven Central, that have moved beyond Java 8.
You should also have a look at Jake Wharton interviews regarding on how the Android team looked up on Flutter, Compose was pratically started as counter movent from the team, there might even still exist on Twitter some of his comments on the subject.
When they were digging in with the Oracle lawsuit, their Android Java support fell behind a bit. And then Kotlin showed up as a drop in replacement and quickly became the default for a lot of Android development. It was so obviously nicer than Java 1.6 that many Android developers didn't bother waiting for kotlin 1.0 to be released even. Java support was eventually upgraded for Android but that took a while. Google made endorsing Kotlin official many years ago. Kotlin is now the preferred language for Android development. And while Java is still supported, using it is probably a mistake for new applications as Java API support increasingly an afterthought in both Android SDKs and the wider library ecosystem.
Google also pushed Flutter as a completely new way of doing UI and targeted it at a completely new OS (Fuchsia) that would replace Android. That never happened and Fuchsia is basically still around on life support but otherwise not going anywhere. Meanwhile, Flutter seems well liked by some but it's also a bit a weird techstack with its own language and compiler and fairly limited integration options. In short that whole techstack seems increasingly a bit of a dead end.
And crucially, Google has always pushed back on the notion of building any support for Kotlin around flutter, which was an obvious thing to start doing years ago. There are some weak arguments about native compilation here. But Java/kotlin were always compiled ahead of time on Android. So, I expect that the dominant arguments here were non technical and boil down to not invented here syndrome.
And now kotlin multiplatform (endorsed last year by Google) and compose multi platform are there. Compose multiplatform is interesting because it extends Google's own framework to other platforms (IOS, Web, Desktop). That has been an obvious thing to work on for a while but Google didn't want to go there because it had Flutter. But now Jetbrains has done it for them. The multiplatform support on IOS is getting quite nice. Native compilation, easy bindings between kotlin and swift code (both ways), etc.
It will be interesting to see if Google rallies behind compose multiplatform as well. IMHO they should and it's an opportunity to get a bit of control over IOS development and wrestle that away from Apple.