Under the current specification of `std::nullopt_t`, it is unspecified
whether certain attempts to construct `std::optional<T>` from nested braced
lists are well-formed, for example:

#include <optional>
struct S1 {
    S1() = default;
};
struct S2 {
    S2(S1) {}
};
std::optional<S2> os{{{}}};

With libstdc++, this actually selects the `std::nullopt_t` overload of the
`std::optional<S2>` constructor, which is then ill-formed because the
constructor of `std::nullopt_t` is explicit.

This problem could be solved if we required the constructor to be something
like this:

class nullopt_t {
    struct token {};
  public:
    constexpr nullopt_t(std::same_as<token> auto);
};

The above constructor template is guaranteed not to accept any argument
that is a *braced-init-list* because deduction will fail.

Do folks think this would be a reasonable proposal? Would it require any
ABI break? (I've never understood which standard library changes require
ABI breaks. It seems like adding and removing non-virtual member functions
is something that has been done before, so maybe this would be ok?)

-- 
*Brian Bi*