Should we keep this consistent with the general synopsis? (Also many other specifications are inconsistent too, like expected<T, E>::operator*(), bad_excepted_access<E>::error() etc.. If we fix this, we may as well fix the others too...)

Another way is to fix the general synopsis to be consistent with const&-&-&&-const&& order, with the additional benefit of be consistent with optional<T>::operator*() and optional<T>::value() (these two are the only case in stdlib where all 4 member function qualifiers overload appears currently). However I don't feel this order is nature than, say const&-&-const&&-&&. (Maybe we should set a new standard for a natural overload order? i.e. fix optional<T> to use const&-&-const&&-&& order too?)

I thought we usually have a non-const overload first, then const. That's what we do or begin() and end() in containers and strings, but then we have operator[] and front() and back() in basic_string where the const overload is first.

I agree we should probably be globally consistent (and IMHO the most natural order is either & const& && const&& or & && const& const&&) but we are already badly inconsistent.

Making this member consistent with the class synopsis makes sense. I don't think we need to rearrange the synopsis for consistency given that we don't have any real consistency.

Just as another datapoint: std::get for array, pair, tuple and variant comes in 4 flavors, too. array, tuple and variant use the &, &&, const&, const&& order, while pair uses &, const&, &&, const&&.

Thus I agree that only consistency with the general synopsis makes sense here.

Let's just float the idea: is there any interest inside WG21 editor team for an editorial PR that makes every member function (overloaded only by qualifiers) in stdlib to become a consistent order (presumably &-const&-&&-const&&/always no-quals before const, since the tradition is to specify first two in a group and next two (often need additional std::move) in other), and thus we can commit to future consistency in new proposals?

If there is interest I may be able to commit time to make a PR when I have spare time.

Can we switch the entire thing to explicit object parameters and avoid the question entirely?
@jwakely , is that an ABI break of concern for the templates we talk about here?

We can and should do it for expected (and that's been suggested previously). We could do it for optional::value and I don't see why it would be an ABI break. Users can't rely on specific signatures for member functions, as per [member.functions], so even if it is a break, an implementation could retain four separate overloads if required for ABI compat.

We can't do it for std::get because those aren't members.

I think if the calling convention of

struct S {
    void fun(int) const &;
}

and

struct S {
    static void fun(const S&, int);
}

is completely the same (which it seems to be, testing on godbolt), then there shouldn't be an ABI break (except that the mangled name is different, and this can be solved by providing aliases).

However a possible scenario is that if we provide it as

template<typename E>
struct unexpected {
    constexpr decltype(auto) value(this auto&& self) noexcept {return std::forward<decltype(self)>(self).unex;}
}

then, I think that for types derivated from unexpected<E> this can be an ABI break: the calling convention between calling unexpected<E>::value() const & (ordinary member) and calling unexpected<E>::value<const Derived&>(this const Derived&) (deducing this) can be different, because the former you need a cast from const Derived& to const unexpected<E>& (which can be not nop, in case of multiple inheritance), and the latter due to template you do not need any cast. A testing is done here.

There cannot possibly be an ABI break for std::unexpected because it doesn't exist in any implementation yet.

And anyway, if the mangled name is different (and it is) then it doesn't matter whether the calling convention is the same or not. It's a different symbol and existing callers of the old symbol (that already have an instantiation of the old definition) cannot be affected by the addition of a new symbol. The only potential problem is if users are relying on explicit instantiations of std::optional, but whether that is supported or not is unspecified and QoI.

But that's all off-topic for an editorial PR.

Ah, yeah, sorry I misunderstand the ABI break scenario… Then that’s great and so think we can change optional/expected to explicit this without any breakage.

Anyways, this needs a new proposal to change and is outside the scope. I think for this PR the only thing we need to done is to change every specification order to match the general synopsis…