Correct, but it doesn't mean that Kotlin concider this type as non nullable, it allows you to decide

if I remember right, there are some cases where the compiler will warn you in an un-annotated assignment if things are ambiguous, but I have no idea when specifically that happens

What's the distinction between "let me decide" and "assume it's not null"?

Difference is that compiler doesn't allow you to use nullable type as non nullable and warn you if you use non nullable as nullable, but platform type is type with unknown nullability that can be used in both ways. Check talk from Andrey Breslav, hi explains this choice. And there is no such flag in compiler. You can find a topic on Kotlin Forum about this with some proposals and comments from Kotlin Team

And hence the million dollar mistake remains unsolved. 🙂

indeed

you cannot solve million dollar mistake for code that already made this mistake. Kotlin used this approach before on some versions before 1.0 (everything is nullable by default), but it’s just not so good solution on practice.

Kotlin + Java = as safe as Java

Yes, but you always free to use Kotlin and have null safety. Also, even in case of using Java API Kotlin do not allow to propagate nulls further But again, maybe make sense to rise this question again and ask for some compiler flag or compiler plugin that force all non-annotated types as nullable. At least it will allow people to test this approach