Nit: match {} brace style from lines 244 and 250. (Ditto line 299.)

I think it is fine to unconditionally define this template. We'll only be using it in C++20, but I don't think it's worth the complexity to add the #if.

We generally don't qualify types in namespace std. So just false_type would be consistent with what we do everywhere. This applies throughout the patch.

I suggest __is_std_optional for consistency with __is_std_{span,array}. I also think there's no need for the __is_optional_v variable template (again for consistency).

(Or, if you absolutely want the variable template for efficiency — which you shouldn't — then I'd say to get rid of the struct template and just specialize the variable template directly.)

Everywhere (for consistency).

Style nit: The Standard calls this U, and I think we should call it _Up. __lower_snake_case looks too much like a local variable to me (and is also verboser than needed). (Alternatively, _Rp; but I think it makes sense to follow the Standard's U.)

The spec says:

Let U be invoke_result_t<F, decltype(std::move(value()))>.
Mandates: remove_cvref_t<U> is a specialization of optional.

I think we should be checking this instead:

static_assert(__is_std_optional<remove_cvref_t<_Up>>::value, ...);

This comment probably applies elsewhere.

I wonder if this should say a specialization of std::optional, without the T, for pedantic correctness. This can totally be done post-commit, though, if we want to, rather than holding up this PR waiting for a round-trip to see if @ldionne agrees or whatever. :)

Note that this qualification of _VSTD::move is good because it protects against ADL. My comment above about qualifications do not apply to cases that prevent ADL from being triggered.

This should be remove_cv_t. Ditto for other instances of transform.

The paper says:

Mandates: U is a non-array object type other than in_place_t or nullopt_t.

Here we're checking that it's not an array, it's not in_place_t, and it's not nullopt_t. But we are not checking that it's an object type. For instance, if __result_type ends up being a function type or void, we won't trigger any static_assert. I'm pretty sure it's going to fail in some other way, but I still think we should check for it explicitly.

This isn't what the paper is expressing. The full wording of the paper is:

Let U be remove_cv_t<invoke_result_t<F, decltype(value())>>.

Mandates: U is a non-array object type other than in_place_t or nullopt_t. The declaration U u(invoke(std::forward<F>(f), value())); is well-formed for some invented variable u. [Note: is_move_constructible_v<U> can be false. -- end note]

Returns: If *this does not contain a value, optional<U>(); otherwise, an optional<U> object whose contained value is initialized as if direct-non-list-initializing an object of type U with invoke(std::forward<F>(f), value()).

What they mean in the Returns: section is that the object inside the optional should be direct-non-list-initialized as-if one had used U u(invoke(std::forward<F>(f), value())); exactly. Combined with the note that U doesn't have to be move-constructible, I am fairly convinced they are telling us to allow move-elision, like what I did in D107932. At the end of the day, I suspect this will have to look something like

optional<__result_type>(__construct_from_invoke_tag{}, _VSTD::forward<_Func>(__f), value());

where there's a special optional constructor that looks like

template<class _Fp, class ..._Args>
constexpr explicit optional(__construct_from_invoke_tag, _Fp&& __f, _Args&& ...__args) 
  : __value_(_VSTD::invoke(_VSTD::forward<_Fp>(__f), _VSTD::forward<_Args>(__args)...)))
{ }

This is of course going to be more complicated due to inheritance and stuff, but you get the idea. Here, at least, we allow move elision to occur.

Also, please add tests for all the methods that have this Note: where __result_type is not move-constructible. Those should fail with your current implementation and they should start working once you implement something like what I just laid out.

Here decltype(std::move(value())) is just _Tp&& (and ditto throughout, with cvref-qualification differences). IMO the shorter _Tp&& form should be used for clarity.
Also, I'm like 95% sure that invoke_result_t<_Func, _Tp&&> is just invoke_result_t<_Func, _Tp> (because it all boils down to declval stuff in the end, and declval can't distinguish xvalues from prvalues).

Not just an optional - it needs to be this particular specialization of optional.