Earlier quoted context omitted.
In any context where you're combining two things that have different kinds of absence. E.g. if you have a cache around an expensive API call, you want to be able to cache null results from that API call, so you need a distinction between "not in the cache" and "cache entry where the API returned null".
Java for example has Map.computeIfAbsent. This function returns a nullable value and does not need 2 layers of if absence to work. I would personally argue that exposing the 2 levels of absence is exposing an implementation details, but I'll accept this as a valid usage of double optionals.
> I would personally argue that exposing the 2 levels of absence is exposing an implementation details
Probably you wouldn't want to return Option> (or Nullable) to outside callers - maybe you want to convert None to one kind of domain-meaningful error and Some(None) to a different kind of domain-meaningful error, maybe you want to take some different codepaths to respond to "recover" from the different kinds of absence.
But it's extremely valuable to be able to compose together existing libraries that might use absence to mean something and have them just do the right thing rather than always having to worry about the edge cases where one has a kind of absence that's subtly different from the other's kind of absence. I mean fundamentally you can't ever assume that a random third-party function in Java is safe to call with null, because many of them aren't. But you also can't ever assume that a random third-party function won't return null, because some of them do. So even to just compose two functions you've got to check their docs and think about the behaviour of this special value, and it's just all so avoidable.