As a simple example of this problem:

In java7, the concept of 'I want to typecheck this expression, and if it is of the type I want, I want to do things to it based on that fact' was unwieldy in java:

-- JAVA 7 CHECK-AND-USE --

  if (x instanceof String) {
      String y = (String) x;
      y.toLowerCase();
  }

kotlin decided to address that:

-- KOTLIN CHECK-AND-USE --

  if (x is String) {
      x.toLowerCase()
  }

within the 'if', x 'updates its type' automatically. Note that if java were to copy this, method dispatch depends on the compile-time type of the arguments, so if java were to apply this behaviour to its instanceof operator, that would break backwards compatibility (existing java code would mean something else just because you updated java versions). The obvious thing happened: Oracle / the JCP rejected this outright. Hence, it doesn't work that way in java and never will.

But this problem WAS tackled by java, and in a much different way: Java has generalized this concept as pattern matching and went all in on that.

-- ACTUAL FUTURE-JAVA --

  // preview feature in 14, will be in 15.
  if (x instanceof String y) {
      y.toLowerCase();
  }

  // -OR--

  if (!(x instanceof String y)) throw new IllegalArgumentException();
  y.toLowerCase();

and, taking pattern matching to the next level:

  // will likely be preview in 15 or 16.
  // Given:

  value class Point {int x, y; }

  if (p instanceof Point(x, y)) {
      // you can use x and y (both int) here
  }

Which goes much further than kotlin and is quite different. So now kotlin has 3 options and they are all bad:

1. Also adopt this syntax. But now there are 2 different ways to do the same thing, so kotlin is now the language that feels like a jumbled mess that needs cleaning up, with pointless style debates and an increased learning curve for no good reason.

2. Ditch their existing syntax and adopt this syntax. That means kotlin breaks their own backwards compatibility, and everybody needs to either accept they can never update their kotlin, or they need to find all spots in their codebase that uses the old construct and update it.

3. Don't adopt this, and be in the situation that java has _more_ language features that kotlin. Or adopt pattern matching differently, at which point the idea that it's 'easy' to switch from java to kotlin starts taking a hit... and likely kotlin's design will start to feel jumbled because features are spliced on ad-hoc and mostly informed by dueling concerns.