Since operator =, [], -> are isolated from the categories a@b, @a, or a@ as described in Table 17, and we didn't explicitly specify whether these operators are unary operators or binary operators, and we just use for a unary operator @ with... and ** for a binary operator @ with...** to introduce [over.match.oper] p3. Hence, the first issue is:

If T1 is a complete class type or a class currently being defined, the set of member candidates is the result of a search for operator@ in the scope of T1;

It seems that the above rule may not cover operator =, [], ->(although, it's not the intent, however, Table 17 and the initial sentence of p3 together hint that).

The second issue is:

[over.match.oper] p3.2

otherwise, it includes the result of unqualified lookup for operator@ in the rewritten function call ([basic.lookup.unqual], [basic.lookup.argdep]), ignoring all member functions.

In [over.match.oper] p2, we introduce the concept transformed function-call notation, I think we should consistently use the utterance operator@ in the transformed function-call instead of "rewritten function call", after all, the wording "rewritten" will be given other meanings in the below paragraphs, using the former can also avoid the misunderstanding.

The third issue is:

[over.match.oper] p7

The argument list contains all of the operands of the operator.

Consider this example

a++;

Since a has a class type, the expression is transformed to a function-call notations (a).operator@ (0) or operator@(a, 0), in either case, the argument list consists of two arguments anyway. According to p7, the expression a++ merely has one operand a(the value 0 is introduced after the expression is transformed to a function-call notation).