Issue #4671 is potentially related to this. I think we could consider auto to be a template parameter that participates in template argument deduction in the manner as [dcl.type.auto.deduct] did. And we are just necessary to give a normative rule to specify how to refer to that specialization.

The (return) type of "operator auto" is deduced from its definition.

#1 is obviously wrong, but we lack wording that describes how "auto" gets transformed to "int" so that #2 is valid. CWG needs to discuss this.

However, "operator auto" should be the declarator-id on grammar, which means the name lookup rule has to use the declarator-id to find out the declaration. Maybe, the rule for "how auto gets transformed to int" would cover this concern.

#1 is obviously wrong

I don't think that's obvious. See prior discussion in http://lists.isocpp.org/core/2018/01/3737.php, which seemed to be leaning towards #1 being correct.

That discussion predates P1787R6, I believe.

[dcl.spec.auto.general] p6 says

A program that uses a placeholder type in a context not explicitly allowed in [dcl.spec.auto] is ill-formed.

The use of auto in an id-expression in the class member access expression is not explicitly allowed in [dcl.spec.auto]. Hence, it can arguably say it's wrong.

I don't think P1787R6 really intended to address this question. To the extent it did anything here, I think it made the problem worse -- after that wording change, I think we no longer consider a function whose name is operator auto when looking for a conversion to int at all (the new [over.match.funcs]p7 looks for a function named operator int, whereas the old wording looked instead at the return types of the conversion functions) -- so I think this corner case was not considered as part of that wording change at all.

The interpretation that I want, consistent with the (unfortunate) fact that operator auto is a deduced return type rather than a conversion function template, is that the function's name, formed as it is from its return type, is operator int. The unadorned alternative doesn't seem reasonable:

struct X {
  virtual operator int() {return 1;}
};
struct Y {
  operator auto() {return 1;}
};
int f(X x) {return x.operator int();}  // OK
int f(Y y) {return y.operator int();}  // error: name lookup failed
struct Y2 : X {
  operator auto() override {return 1;}  // error: doesn't override
};

This was, I believe, at least my subconscious intent in writing P1787.

Since we can't refer to a function with an undeduced return type, this almost works even for a function that has been declared but not defined:

struct Z {
  operator auto();
};
void f(Z z) {
  z.operator auto();  // error: name lookup failed
  z.operator int();   // error: maybe you guessed its name right, but you can't call it here
}

However, it breaks down if we try to do more than that:

struct W {
  operator auto();
  operator auto();  // ???
};

Of course, neither does it really work to just say that operator auto is the name:

struct V {
  operator auto();
  operator auto*();  // OK...
  static int i;
};
V::operator auto() {return &i;}
V::operator auto*() {return &i;}
int *p=V();  // what does this call?

If we do say that operator auto is the name, perhaps what we need is a special-purpose lookup rule "If you look for operator T, you also find any function whose name is operator auto whose return type is T.", although there would still be the question of what to do if the return type is not (yet) known. We could also make lookup for operator auto never find anything: being able to call y.operator auto() seems to have even less expected value than is usual for calling conversion functions by name.

@opensdh, I'm wondering whether that discussion should be on the CWG e-mail reflector, with reference to CWG2493 and CWG1670, rather than on an editorial issue, which this topic definitely isn't.