Sometimes you'll have nested Options just because you're mapping a fallible operation over a fallible input. You don't want the resulting `Option<Option<T>>` to immediately collapse; then you wouldn't know which upstream operation failed. It's true that `Option<Option<T>>` is very generic (i.e. it doesn't inherently tell you what each None means), but flattening Options removes more information; it isn't a solution to the problem you're posing. At least you can post-process an `Option<Option<T>>` into a multi-variant, self-documenting result type before you pass the value off to some other consumer.

In other words, nested optionals might not be very readable, but they're a necessary product of having a highly modular, reusable toolkit, and you can always massage them into more informative, domain-specific types at whatever point that becomes appropriate.

The biggest impact is on generic code - you don't want supplying Foo? as T rather than Foo to mean that there are side effects where successful returns and error cases are both represented by null.

In some cases (limited) nesting really seems useful. Nullable parameters for a Copywith method is another one (does null value mean 'no change' or 'set it to null').

The thing is that nullable covers majority of cases and is quicker to read and write (Foo? vs Option<Foo>). Doing a?.b?.c is also more elegant than anything equivalent using an Option type.

Is there any languages that successfully combines both, nullable '?' syntax and an Option type?

The Haskell equivalent `c <$> b <$> a` is roughly as concise.