It already could be a reference type from a template argument, no?

@timsong-cpp: True—and we also consider function parameter and return types, so this is entirely preexisting.

I think [basic.lookup.argdep] is fine for cv-qualified types. Cv-qualified types are versions of their cv-unqualified types, and so are of the same categories (eg, int *const is a pointer type). So I think only the reference-type portion is in scope here. For

namespace N {
    struct X {};
    void f(void (N::X&));
}
void g(N::X&);
void h() { f(g); }

I think the language rules are clear that the call is ill-formed, but all implementations accept. I can't bring myself to see fixing this as being editorial; please file a core issue (and let us know when that's done so this can be closed).

Cv-qualified types are versions of their cv-unqualified types, and so are of the same categories (eg, int *const is a pointer type).

I don't think we state that clearly; for example, [basic.types]/9 says that

Arithmetic types (6.8.1), enumeration types, pointer types, pointer-to-member types (6.8.2), std::nullptr_t, and cv-qualified (6.8.3) versions of these types are collectively called scalar types.

and [basic.fundamental]/1 says that there are 5 (not 20) standard signed integer types.

Am I misinterpreting [basic.types], or do we need some sort of correction there if not in [basic.lookup.argdep]?

[basic.fundamental]/1 says that there are 5 (not 20) standard signed integer types

[class.name]/1 says «A class definition introduces a new type». Shouldn't it say that 4 types are introduced?

Also, shall const T class type have the same members as T? [basic.type.qualifier]/1 only says that const T shall have the same representation and alignment requirement as T, but this doesn't prohibit rename of members (say, from N to c_N) and/or addition of qualifiers to their types. (https://stackoverflow.com/questions/61568349/decltype-of-qualified-id-denoting-class-member-with-const-t-vs-t-in-nested-name-specifier)