Hi Connor,
Your paper suffers from long Latinate sentences and (in some places) the
* bolding* and sycophancy characteristic of ChatGPT output.

> We propose moving the boundary from *declaration presence* to
*applicability*, represented by candidate viability when overload
resolution applies.
> [...]
> P2279R0 identifies non-intrusive opt-in as an important property of
customization mechanisms and specifically observes that ADL-based
free-function customization provides it. It also observes that ADL does not
provide a genuine explicit marker of the interface into which a declaration
intends to opt.
> [...]
> This is a real tradeoff. [...] This is ultimately a question about
inferred intent.
> [...and so on.]

If you can find a way to cut down the verbiage and write in
plainer English, that would help. The paper probably doesn't need to be 8
pages long, either.

You introduce P0962R1 by paper-number, but never mention its title, and
it's not until the very end of §4 you mention that "P0962R1 was adopted as
a Defect Report." (Until then, you'd carefully avoided mentioning whether
P0962R1 was even discussed, let alone accepted!) So in your Figure 2,
"C++11" means "C++11 as originally shipped" and "P0962R1" means "C++11
after the DR." It would be good to mention some years, too. IIUC, P0962 was
adopted sometime around 2018 or 2019?

Nit: In your Table 1, some of the "Case"s end with "+ ADL", and some don't.
But if I understand correctly, *all* of them should equally end with "+
ADL".

As for the proposed change itself: A big thank-you for including
plausible-looking Proposed Wording in your paper! Most first-timers don't
do that, and it makes it hard to tell what they're even proposing. Your
paper has very good Proposed Wording IMHO.
However, I *don't like* the effect of its Proposed Wording. You're making
this one obscure paragraph more complicated — introducing this
case-distinction about whether `range.begin()` has overload resolution
applied to it or not — for what seems to me like essentially zero benefit.
My interest in this area is consistency (which means library-vendor
convenience). As my blog post says, it's bad that `for (auto&& elt : r)`
and `ranges::for_each(r, ...)` can observe completely different elements
and therefore STL vendors can't freely choose between them — they must
lawyer up every time. That inconsistency is what I want fixed. At the end
of §2 you correctly write:
> *This paper does not address the “together versus separate” difference.*
Range-based for continues to select `begin` and `end` through the same
[inconsistent] mechanism.
So, your paper does not fix the *one* thing I think *would* be worth fixing.

What is the benefit of the change that you *are* proposing? As far as I can
tell from §2, your proposal would permit people to write classes like
`legacy::linked_list`, which uses `begin` and `end` as (public) data member
names instead of member functions, and then sort of hack ranged-for into
working on such a type anyway by overloading `begin(r)` to do something
different. But `legacy::linked_list` seems like a terrible idea! I don't
*want* people to write bad code like that, and I don't want to complicate
the standard's wording just to enable them to write bad code.
And consider a similar `legacy::vector`, which uses `begin` and `end` as
public *member function* names that just happen to have the wrong
semantics. Does your proposal allow people to sort of hack ranged-for into
working on such a `legacy::vector` by overloading `begin(r)`? No, it
doesn't. So even given that you're tackling a problem that I don't think
deserves solving (i.e. enabling people to write bad code), you're still not
solving *that* problem completely.

In my blog post
<https://quuxplusone.github.io/blog/2024/12/09/foreach-versus-for/> I wrote:

[The status quo] is awful, for both library vendors and users, because
> instantiating ranges::for_each is vastly slower than just using the
> core-language control-flow construct. It would be a better world if
> library vendors were somehow permitted to use the core-language for loop
> in their algorithms [.]


LWG4389's two proposed resolutions seem to be aiming in that direction, if
I understand them correctly.
Your proposal does *not* seem to be aiming in that direction, if I
understand it correctly.

It would help if your paper would explicitly claim either "Adopting this
proposal would resolve LWG4389, permitting library vendors to use `for` in
place of `ranges::for_each`," or vice versa (that it wouldn't do so).

HTH,
Arthur