computeIfAbsent doesn't need a second kind of absence because it can never return absence. That's fine if that API is a good fit for your use case, but it isn't always (there's a reason Map.get exists as well as Map.computeIfAbsent).

> I would personally argue that exposing the 2 levels of absence is exposing an implementation details

Probably you wouldn't want to return Option<Option<X>> (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.

How about a situation where the inner Optional<T> is acquired from another system or database, and the outer Optional<Optional<T>> is a local cache of the value. If the outer Optional is null, then you need to query the other system. If the outer Optional is filled and the inner Optional is null, then you know that the other system explicitly has no value for the data item, and can skip the query. Seems like using nested optionals would be natural here, although of course alternative representations are possible.

In JSON/REST API bindings, where a deserializer maps JSON to language-native object/struct type, I'll often need to know the difference between:

    {}

and

    { "foo": null }

and

    { "foo": 42 }

So I'll represent that (in e.g. Rust) as:

    struct Whatever {
        foo: Option<Option<u32>>,
    }

None means not present, Some(None) means present but null, and Some(Some(42)) means present with a value.

I'll often use this in PATCH endpoints, where not-present means to leave the current value alone, null means to unset it, and a value means to set to that value.