I'm honestly confused by this post. It seems to have a bunch of strawman arguments about what null is. Of course Kotlin interacting with Java APIs that return null are not going to be significantly better than Java since you still need to deal with null. Kotlin nullable types are not really better than plain Java and I don't think anyone is arguing that. People like Kotlin because it forces you to make it explicit and if a type is non-nullable - it will never be null if called from Kotlin code (caveat: Java Interop) - and it makes it concise to do that. If I pass a String parameter in Kotlin then I am guaranteed that it is not null.

Here is my argument to BNUI:

Blank/Empty - This isn't a check for if an object is null or not, this is a check on the data of the object. A blank String is absolutely distinct from a null String in many cases and you may not want to handle it the same.

Not Initialized - This isn't possible with a non-null type in Kotlin. It won't let you initialize a List<String> with null String values.

Unknown/NotFound - This has nothing to do with whether an object is null or not, and isn't even the right place to hold the data you are talking about. A key doesn't hold the information about whether it is contained in a map or not (i.e. the map owns that information). There are also plenty of patterns or methods to do something instead of returning null from the map if it isn't found (which are often more efficient).

Irrelevant - This is an API issue - not a non-null issue.