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.