[over.match.funcs.general] p5 user-defined conversions sequence are not considered for object parameter CWG2557

[over.match.funcs.general] p5 says

The implicit object parameter, however, retains its identity since no user-defined conversions can be applied to achieve a type match with it.

It sounds like a note. The implicit conversion sequence only considered whether converting an argument to the type of the parameter can form an implicit conversion sequence. So, "retains its identity" is not matter with the reason why user-defined conversions cannot be applied. Consider this example:

struct A{
   void show(){}
   static void fun(){}
};
struct B{
    using type = A;
    operator A(){
      return A{};
    }
};
B bobj;
bobj.type::show();  // non-static member function  // #1
bobj.type::fun();  // static member function  #2

Even though [class.mfct.non.static] p2 says

If a non-static member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

However, it restricts nothing on the conversion sequence that converts the implicit object argument to the type of the object parameter.

It is even worse the status quo is not clear for a static member function. [over.match.funcs.general] p4 says

For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded).

which bullet can interpret why #2 is ill-formed? neither [basic.lookup], [expr.ref], nor [over.match.funcs.general]

I think we should have a formal rule in a similar manner as [over.best.ics.general] p4, in that subclause, it is a reasonable place to talk about conversion sequence.

Such as

User-defined conversion sequences are not considered if the target is the (implicit) object parameter of a member function

[over.match.funcs.general] p5 can refer to the added rule. In addition, the original [over.match.funcs.general] p5 does not cover explicit object parameter, does it mean user-defined conversion sequence can be considered for it?

For the static member case at #2, I haven't found a corresponding rule that can interpret the ill-formed.

Start by reading [over.match.funcs.general] paragraphs 4–5, [over.best.ics.general] paragraph 4, and [class.mfct.non.static] paragraph 2. Compare the #1 and #2 examples and the linked compiler result; done means the wording clearly resolves user-defined conversions for implicit, explicit, and static member-function object cases.