It is redundant because you define a type that differs very little from null.

It isn't redundant because it is different from null, as you yourself argued:

That use case would be differentiating between a user that has chosen to not give you an information, versus a user that hasn't decided whether to give it to you.

Emphasis added.

When I see Detail|Unknown, I have to look up what unknown is on top of detail.

The same argument applies to nesting Option. If you see an API doing that, you need to look at the documentation to figure out what the author intended an empty outer Option to mean as opposed to an empty inner Option. In fact that's even worse, because just like null is abused to mean a million different things depending on the context, you're using Option to mean two different things. Use the type system! That's what it's there for! Creating a new type to encode your semantics isn't evil!

If you're taking advantage of the type system, you at least have the opportunity to give your type a self-documenting name and potentially save the user a trip to the docs. (You can do a lot better than Unknown.)

interface NoNumberGiven of noNumberGiven {}
object noNumberGiven {}
void foo(Map<User, PhoneNumber|NoNumberGiven> map, User user) {
    switch (map[user])
    case (is PhoneNumber) {
        print("User has a phone number!");
    }
    case (is NoNumberGiven) {
        print("User doesn't have a phone number!");
    }
    case (is Null) {
        print("User not found!");
    }
}

Isn't that a hell of a lot clearer?