The new Collections API wasn't incompatible with kotlin, it is just you can use the new API if you target Java 6 (which makes sense). But you can use the new API if you target Java 8. So I don't see a big deal here.
The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java.
A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.
Quoting: "Sometime ago we introduced kotlin.Stream<T> type, with the simples possible interface – iterator() function – with the idea that we can make it compatible with Java8 Stream<T> type. Currently we seem to come to a conclusion it was a mistake as we cannot fine a way to represent Stream<T> as kotlin type in Java 6 & 7, and then use to Java8's Stream<T> when targeting JDK8. If you have any idea about how to make it work – please share!"
Basically, while Kotlin is more or less a straightforward extension of the Java 6'th Collections APIs, by Java 8's release the two have diverged. When programming in Kotlin, you would normally use its own functional APIs, not Java Streams API. While technically nothing prevents you from using Streams, they don't fully integrate with Kotlin's native Collections, so you're forced to choose one or another.
That more or less what I said, it is not incompatible as you can use the Java stream API if you target Java 8. But yes, it is a pain when you see you have to use the Java Stream API instead of the kotlin Stream API.
Not incompatible but an issue. And they seem to have resolved it. Look at last comment. What you are quoting is from December 14th, before even the initial 1.0 release of kotlin.
Like I said, Kotlin is chasing after a moving target. The issues might be kinda-solvable (even if it requires significantly diverging from Java's APIs), but things inevitably get messier both for the language internals and for users.
The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java.
A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.