Kotlin managed it in some cases with clever forwards compatible type system tricks, so it's not impossible
It's the same strategy here. Carbon is (was?) also intended to compile to the C++ ABI and so does Circle, that's why it says it doesn't run on Windows (commercially a huge error. many of the biggest C++ codebases that could benefit are running on Windows like game engines, and Windows doesn't impose a specific C++ ABI anyway). But there's no way to take existing code files and switch them to the new language in Carbon, at least not yet. Kotlin was carefully designed at every step of the way such that every Java program can be expressed in Kotlin without change, even if that meant compromising on some things. Seems like the Carbon guys are being sucked up by the lure of safetyism and just want to make their own version of Rust that happens to compile to the Itanium C++ ABI.
Loom, value types, SIMD, Panama,... are all features that start to be an issue to expose as Kotlin features.
It is working on Android, because Google is pushing it as Java 8 => Kotlin, not as Java XYZ <=> Kotlin.
SIMD/Panama stuff is just new APIs. No problem there. Kotlin maybe even wins because Panama is super verbose.
JVM value types seems never to arrive. Stuck in dev hell for years maybe. If/when it ever does see the light of day, Kotlin has value types and so it can just be compiled to a JVM value type to get the benefits. You'd need to opt in to an ABI break but no big deal.
So the binary compatibility part hardly seems an issue even looking forward a long way into the future.
It's probably harder for C++ because the language there seems to evolve quicker than Java!
KMP taken to the extreme, is better for Kotlin just to do its own thing with Kotlin/Native, except it is so behind that JetBrains is using Rust instead for Fleet services.
Java is expected to have language level support for some of those features, will Kotlin catch up?