It's not at all clear to me that this change is editorial (i.e. not changing semantics for corner cases), so (personally), I'd prefer a paper approved by LWG. Specifically, could you elaborate why the deleted overloads were necessary before, but no longer so?

Further, I'm not sure that "only ADL" is implementable in plain C++ (which, of course, does not necessarily constrain the standard library). For example, given

int strong_order(X,Y);
#include <stdlib_header>

it seems that strong_order may have been found previously (since unqualified lookup inside stdlib_header may eventually reach the global scope), but now you're not supposed to find that unless X or Y are declared in global scope.

Specifically, could you elaborate why the deleted overloads were necessary before, but no longer so?

My understanding (and maybe @ericniebler and/or @CaseyCarter could weigh in with better understanding) is that the "poison-pill" overloads in range-v3 are needed because range-v3 is a C++14-compatible library. In C++14, std::swap (for example) was an unconstrained template.[*] Adding a new deleted overload was needed in order to stop std::mutex m1, m2; std::ranges::swap(m1, m2); from accidentally dispatching to std::swap<std::mutex> and producing a hard error instead of SFINAE-friendliness. In C++17, std::swap<std::mutex> does not participate in overload resolution, so we do not worry that the ADL-only lookup of swap(m1, m2) might choose it.

Further, I'm not sure that "only ADL" is implementable in plain C++

This seems very worrisome if true! But I don't understand your example. Here's my attempt to reproduce it with swap as an example: https://ranges.godbolt.org/z/zRUvCb
The implementation strategy for "ADL-only lookup" remains the same: the library implementor puts some untenable overload of swap (or strong_order) somewhere in the detail namespace that actually makes the call, so that unqualified lookup finds that untenable thing and stops before finding std::swap. It's just that in C++17, the untenable declaration doesn't need to have precisely the specified poison-pill form; it might be as simple as int swap();.
Example of what I'm thinking: https://godbolt.org/z/AEdYPd

[*] — That is, according to cppreference. According to libc++, it's been constrained since 2011. According to N4140 (C++14), it was constrained but only via SFINAE in its noexcept clause — admittedly too subtle.

Thanks for the explanation. It seems the "int swap()" poison-pill is actually better than the previous form, because it stops non-ADL name lookup, but otherwise is non-viable and doesn't interfere with overload resolution. Consider https://ranges.godbolt.org/z/2VMmyq :
Obviously, my template swap in namespace N is found via ADL (status quo of the example), however, ranges::swap doesn't find it (remove comment marker to see it). At least this implementation seems to violate the "nothing but ADL" rule.
Even if my template swap were found, it would produce an overload ambiguity with the hitherto-prescribed poison pill, whereas the new wording doesn't. That at least seems like a normative (i.e. non-editorial) change to me.

Consider https://ranges.godbolt.org/z/2VMmyq : Obviously, my [completely unconstrained] template swap in namespace N is found via ADL (status quo of the example), however, ranges::swap doesn't find it [...]

Hmm, good point. This change is far from editorial (but still, IMO, good! ;)) and needs a defect/paper. At the very least, your example shows that the current explanatory wording in [customization.point.object] is incorrect:

To preclude such an expression resulting in a call to unconstrained functions [sic]
with the same name in namespace \tcode{std}, [...]

The currently specified poison-pill also blocks unconstrained function templates with the same name in associated namespaces! Which, as you say, means that the current poison-pill approach is not the same thing as "ADL-only lookup."

Also, [customization.point.object] means "unconstrained" in the literal C++2a-lawyer sense. For example, this template is considered "unconstrained" by C++2a and by Ranges-V3, even though someone coming from C++17 would probably have said colloquially that it was "constrained" to accept only Ts derived from N::A.

template<class T>
std::enable_if_t<std::is_base_of<N::A, T>::value>
swap(T&, T&) { /* something */ }

One might plausibly argue that users who write completely unconstrained, C++03-swap-style, templates deserve what they get — but I don't think we should ship a ranges::swap that claims to do ADL-only lookup yet quietly ignores this kind of "colloquially constrained" ADL template.

We seem to agree the changes are not editorial. Could I kindly ask you to take the matter to LWG via their reflector and/or via their issues list?

Which, as you say, means that the current poison-pill approach is not the same thing as "ADL-only lookup."

We're trying to express that overload resolution is performed on a set of functions and function templates that includes the poison pill(s) as well as the results of ADL-only name lookup.

@Quuxplusone, is there some editorial cleanup/harmonization left that you wish to have applied given @CaseyCarter's comments, or is this all LWG material?

@Quuxplusone, ping?

@Quuxplusone, is there some editorial cleanup/harmonization left that you wish to have applied given @CaseyCarter's comments, or is this all LWG material?

I don't think I'm likely to do anything else with this PR, so I think it should just be closed at this point.