Nit, but let's be consistent. Here and below.

I would *not* guard this with _LIBCPP_STD_VER since this is internal. We can guard the top-level swap on std::tuple only.

Since this is new code, I would recommend not using inline here.

Please use __x and __y for consistency with lines 201–207.
Separately, don't you need a noexcept-spec similar to line 204?

Same, I would *not* guard this with _LIBCPP_STD_VER since this is internal.

No action required, but it looks slightly odd that this uses noexcept directly whereas the one above uses _NOEXCEPT_ . Ditto for the new swap implemented below.

Since this is C++17-or-later, you can use noexcept((is_nothrow_swappable_v<const _Tp&> && ...))

Is there a reason for not doing it like we do for non-const types? Let's use the same approach for consistency, whatever that is.

This comment is now incorrect, I would say instead tuple([const] tuple<U...>&) constructors (including allocator_arg_t variants) or something like that.

The && comment below is also incorrect now -- please audit to make sure there aren't others too.

Really small nitpick, but we generally use ctor instead of ctr for constructor (at least it's what I've seen so far).

What happens if you remove these conditions? The comments should explain what is the behavior that we are preserving.

What's __maybe_const? Should it be in this patch?

I don't like making these sorts of comments, but I don't understand why the indentation was changed. It used to be lined up to tabs.

I'm not requesting it, however if you'd like to add a regression test where for example _BoolConstant<sizeof...(_Tp) != 1> is false, but evaluating is_constructible<_Tp, _OtherTuple> is a hard error, I think it would catch this.

Mentioning _Not<T> does not instantiate T immediately, it only does when you do _Not<T>::whatever. Since you only do that lazily with my suggested edits to _And and _Or, you don't need _Lazy at this level anymore -- at least I think you don't, but our tests should tell you if I'm right.

(1) Can't use requires because of _LIBCPP_HAS_NO_CONCEPTS.
(2) Don't want to use requires because what you actually meant is sizeof...(_Up) == sizeof...(_Tp) should be true, not just well-formed. I'd go so far as to claim that in libc++ contexts, mixing enable_if_t with requires is always wrong. (But maybe that's trivially true because if you were able to use requires you wouldn't need enable_if_t to express a constraint.)
(3) __enable_if_t<sizeof...(_Up) == sizeof...(_Tp) && _EnableCopyFromOtherTuple<_Up...>::value>* = nullptr

Right? (Please add a regression test.)

Bikeshed: should explicit(...) be indented on lines 751 and 759? Personally I think not. It's not a "subordinate" clause in any sense; we don't normally indent the return type or constexpr when that's on a line by itself.
Significant: I assume you mean explicit(!(...)), right? Haven't checked the wording, but I would guess we want the ctor to be implicit only if all the types are convertible, not explicit. Please add a regression test for each of these explicits; you can check by temporarily removing the ! from one at a time, and making sure that some test fails, for each of them.

You're going to need the same bool _Const technique here. Please add a regression test that can detect the problem (e.g. via a type A where A&& is convertible to B but B(const A&&)=delete, and vice versa).

Don't you need to make changes here too to pass _Const and use __maybe_const<_Const, _Tp>&& instead? I think this should look like:

template <bool _Const, class ..._Up>
struct _EnableMoveFromOtherTuple : _And<
    _Not<is_same<tuple<_Tp...>, tuple<_Up...> > >,
    _Lazy<_Or,
        _BoolConstant<sizeof...(_Tp) != 1>,
        // _Tp and _Up are 1-element packs - the pack expansions look
        // weird to avoid tripping up the type traits in degenerate cases
        _Lazy<_And,
            _Not<is_convertible<__maybe_const<_Const, tuple<_Up>>&&, _Tp> >...,
            _Not<is_constructible<_Tp, __maybe_const<_Const, tuple<_Up>>&& > >...
        >
    >,
    is_constructible<_Tp, __maybe_const<_Const, _Up>&&>...
> { };

This should be observable if you have a type Foo in your tuple like this:

struct Foo {
  Foo(Other const&&);
  Foo(Other&&) = delete;
};

If you use is_constructible<_Tp, _Up> (where _Tp=Foo and _Up=Other), we'll prefer the Foo(Other&&) constructor and the answer will be "no". If we use my proposed version, it should use Foo(Other const&&) instead and be satisfied.

https://godbolt.org/z/b47ffv43P

Please add a test for this in all the constructors that take rvalue-refs.

& should presumably be &&; please add a regression test.

It's pretty obvious, but just to stay consistent with the other constructors above. This also applies to the other constructors below.

If we don't have 2 types in the tuple, we shouldn't even be attempting this is_convertible check on the first one.

Don't instantiate any constructability/convertability checks in tuple if there are obvious reasons why the constructor evaluating them shouldn't be chosen, such as the arity.

Again I haven't checked the wording (just cppreference), but this feels convoluted and thus wrong. It should be more like:

• EnableImplicitMoveFromPair if both types are implicitly convertible
• EnableExplicitMoveFromPair if both types are explicitly constructible and not EnableImplicitMoveFromPair

Which I think is how it was.
The only thing C++23 changes, AFAIK, is that now we've got two more ctors taking pair& and const pair&& in addition to C++11's const pair& and pair&&.

Actually I think your way of doing it below (lines 987-1012) is fine, except that you're misusing requires again — and you probably need to #if _LIBCPP_STD_VER <= 20 the existing ctors from pair, so that in C++23 we get only the new conditionally-explicit four below.

Minor stylistic thing, but I'd do class _Alloc, class _U1, Class _U2 on the same line for consistency with the rest of the code in this file.

For comparison against line 1101, I think it'd be best to use is_assignable<X&, Y> for every one of these conditions, rather than switching from is_assignable to is_copy_assignable/is_move_assignable in special cases.
Chesterton's Fence on the use of _And rather than __all: I suspect there's a reason we want the short-circuiting behavior here. Please adjust line 1101 the same way. (Again, the guideline is "be consistent with pre-existing code unless you understand why the old code must be wrong.")

We could use requires instead since we are in C++ > 20 and we only support compilers that support concepts.

I don't know that we need to do the _If trick here. Because it's not the true "copy assignment operator", we don't need to worry about the compiler generating one.

Try writing these like normal overloads with normal SFINAE.

Are we implementing this for std::array too?

I like that you use _BoolConstant<sizeof...(_Tp) == sizeof...(_UTypes)> for self-documentation of the condition, however technically it is not needed because is_assignable<const _Tp&, const _UTypes&>... would SFINAE-away if that were not the case. I suggest you leave as-is for documentation purposes, I just wanted to point it out.

I think we should either use _EnableAssignFromPair with the const and the non-const overloads, or simplify _EnableAssignFromPair to always assume that _Const == true. Otherwise, this code looks buggy, even though it isn't.

IMO it's not necessary for such a small block.

What's with the reference here

Ditto.