Remove best-effort rule, make it a lint instead

Author: josh11b

proposals/p3720.md

@@ -38,6 +38,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Reference binding produces a value that wraps a pointer](#reference-binding-produces-a-value-that-wraps-a-pointer)
     -   [Separate interface for compile-time binding instead of type binding](#separate-interface-for-compile-time-binding-instead-of-type-binding)
     -   [Allow `extend api` of an incomplete type](#allow-extend-api-of-an-incomplete-type)
+    -   [Make some name resolutions cases unambiguous with `extend api`](#make-some-name-resolutions-cases-unambiguous-with-extend-api)
 
 <!-- tocstop -->
 
@@ -262,22 +263,24 @@ How does this arise?
 > [member_access.md](/docs/design/expressions/member_access.md) says that
 > `v.(C.Static)` and `r.(C.Static)` are both invalid, because they don't perform
 > member name lookup, instance binding, nor impl lookup -- the `v.` and `r.`
-> portions are redundant. That rule is now a best-effort diagnostic and should
-> not trigger as the result of rewrites performed by the compiler or when the
-> problem is not contained in a single expression. For example, it would be
-> reasonable for the compiler to allow:
+> portions are redundant. That rule is removed by this proposal.
+>
+> Instead, tools such as linters can option such code as suspicious on a
+> best-effort basis, particularly when the issue is contained in a single
+> expression. Such tools may still allow code that performs the same operation
+> across multiple statements, as in:
 >
 > ```carbon
 > let M:! auto = C.Static
 > v.(M)();
 > r.(M)();
 > ```
 >
-> Note that with overloaded names, the `M` might be an instance member in some
+> Note that if `M` is an overloaded name, it could be an instance member in some
 > cases and a non-instance member in others, depending on the arguments passed.
-> Since the call happens after binding, this gives another reason to consider
-> this a best-effort error on a whole expression, rather than a strict rule just
-> about binding.
+> This is another reason to delegate this to linters on a best-effort error
+> basis analyzing a whole expression, rather than a strict rule just about
+> binding.
 
 The binding operators are defined using three dedicated interfaces:
 
@@ -1266,3 +1269,8 @@ This was discussed in the
 [proposal review](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1507988547)
 and
 [the #typesystem channel on Discord](https://discord.com/channels/655572317891461132/708431657849585705/1217499991329738852).
+
+### Make some name resolutions cases unambiguous with `extend api`
+
+TODO: See
+[comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1513671030)