Working around those problems via Option<Option<T>> does not solve them either. When you have multiple reasons for a missing value, make it more explicit, don’t use null/nil/None/Nothing (or whatever it is called in your language) everywhere if you want to distinguish different cases. Be more explicit. Case in point:

RxJava suffered from this and they ended up disallowing nullable values inside Observables because they used it as a marker for internal behaviors

The mistake is using null as a marker for internal behaviors. You could go and fix it, no need to blame null here. What if I use an empty string “” as a marker in my code? Does it give me justification to say that my users are not allowed to store empty strings in my data structure? That is a lame excuse.

In kotlinx.coroutines some of our classes have may different markers for various internal behaviors and none of them prevent users from storing or transferring any data type they might want. All the markers or wrappers we use are our internal implementation details and they should not leak outside.