We just hired a Kotlin person (really a Java guy who refreshed his Kotlin over the weekend) for this, and we may be hiring more.
I suspect more companies will start looking at Kotlin in the next 2-3 years, especially for green field projects.
I have heard lots about Kotlin though, and it sounds like most devs that've touched it are huge fans.
I have noticed something like what you describe with Groovy though. We've had groovy enthusiasts that have peppered our java codebases with Groovy. It's not viral or contagious, and ultimately just served to confuse matters and make the code harder to understand. We've had more than a couple of refactor efforts to get rid of groovy code and turn it back into java.
Sure, Java interop will make some code parts look a lot more like Java then like Kotlin, but I can't personally imagine that a team would decide to switch back to Java-only after using Kotlin for a while. Interested to be proven wrong if someone has seen that happen.
I think that you need to separate out languages that are intended for bidirectional interop (Kotlin/Groovy) from those that provide excellent one-way interop (language uses Java APIs) but less optimal interop the other way (Java uses code written natively in language).
Groovy and Kotlin have great bidirectional interop while Clojure and Scala don't map over nearly as well.
> it smells like after a while non-Java projects could just become Java projects?
Almost never happens in my experience, Java is just too suboptimal compared to these other languages. Once I started using Groovy in a few places it quickly becomes the case that I wanted to use it absolutely everywhere I can - it's just too much better.
I do code it in a much more static style than is often used in Groovy more generally though (declaring types whenever it helps readability, etc). I also always want to define interfaces and key data structures in pure Java if there's no reason to have them written in a different language.