The only ones I can think of are where the language provides a feature that automates some Java boilerplate, so it wouldn't make sense to write things out by hand anymore. Otherwise they're semantically identical languages so the gap isn't big.
IMO there's a contradiction at the heart of Kotlin's positioning. As the quote goes, a language that doesn't affect the way you think about programming, is not worth knowing. If programming Kotlin is just like programming Java, why not just keep programming Java? If you want to switch to Kotlin because it's going to unlock a better way of programming, then that's going to have to mean changing how you program. It may work as a trick to get users on board at the start, but ultimately the language will have to find its own idioms and patterns, or else go the way of CoffeeScript.
> This is not the case with Kotlin at all. The Android ecosystem started transitioning to Kotlin long before Google recommended that and before Kotlin 1.0 because the pain of having to deal with Java 6/7 just made that development so much better. A few years ago they started endorsing and recommending it and at this point they are clearly deprecating a lot of stuff that they did for Java that can be done better with Kotlin e.g. embracing co-routines over rxjava, adding extension functions and kotlin dsls and designing new features that really only make sense if you use Kotlin. On Android, if you are doing Java, you are working on a legacy code base.
There's a contradiction between your paragraphs; my experience is that as Kotlin projects mature, they also reach a point where developers frown on Java idioms. I mean fundamentally either the language is different from Java or it isn't; if it is, the transition isn't going to be seamless, and if it isn't, then why use it? The Kotlin community may have been better at being supportive, but the practical experience of making the transition is exactly the same (e.g. I used Spring for my early Scala projects, and found that to be a very nice way of working).