Nullable types are fine. The key is to make them explicitly nullable, so that programmers are allowed to use non-nullable types as well.

Both need to be permitted. Ideally by way of sum types, but Kotlin's approach should be okay.

Why do you need both? Are there use cases for null that are not covered by a (non-nullable) type with present and absent variants?

I think the distinction between nullable types and the non-nullable types you speak of is fairly narrow, you've just made it type safe (which isn't a bad thing!).

I don't necessarily disagree, what I don't understand is the parent comment's use of the word "need" in "Both need to be permitted". It makes me think there is something nullable types can do that non-nullable types can't do, and I'm just not sure what that is. Something like "it is fine to permit both" would make sense to me.

I guess maybe it's because in a language with no value types (like anything on the jvm), using Optionals everywhere requires a lot more objects to be allocated, so in allocation-sensitive code it might make more sense to use nulls instead.