[namespace.udecl] does not explicitly state the reason for special member hidden

[namespace.udecl] p4 states

If a constructor or assignment operator brought from a base class into a derived class has the signature of a copy/move constructor or assignment operator for the derived class ([class.copy.ctor], [class.copy.assign]), the using-declaration does not by itself suppress the implicit declaration of the derived class member; the member from the base class is hidden or overridden by the implicitly-declared copy/move constructor or assignment operator of the derived class, as described below.

The only possible relevant paragraph referred to by as described below may be [namespace.udecl] p11

The set of declarations named by a using-declarator that inhabits a class C does not include member functions and member function templates of a base class that correspond to (and thus would conflict with) a declaration of a function or function template in C.

Consider this formal example:

struct A{
  A(A &&);
};
struct B:A{
  using A::A;
  B(B const&);
}
extern B b1;
B b2 = static_cast<B&&>(b1);

This case is just clarified by [over.match.funcs#general-9] rather than by [namespace.udecl] itself. [namespace.udecl] p11 requires that two member function should correspond. In this case, A(A &&) does not correspond to B(B const&), as per [basic.scope#scope-4.3]

each declares a function or function template, except when

• both declare functions with the same non-object-parameter-type-list, equivalent ([temp.over.link]) trailing requires-clauses (if any, except as specified in [temp.friend]), and, if both are non-static members, they have corresponding object parameters, or

They do not have the same non-object-parameter-type-list, thus they do not correspond. So, what does the as described below refer to, for the "copy/move constructor or assignment operator" case?

The definition of corresponds also has a defect for constructors. A constructor is a member function, nonetheless, we never clarify whether such a function is a non-static member function or not through [class.mem#general-4].

A data member or member function may be declared static in its member-declaration, in which case it is a static member (see [class.static]) (a static data member ([class.static.data]) or static member function ([class.static.mfct]), respectively) of the class. Any other data member or member function is a non-static member (a non-static data member or non-static member function ([class.mfct.non-static]), respectively).

So, for a constructor, it falls into the "Any other data member or member function is a non-static member" branch?

This point impacts "if both are non-static members, they have corresponding object parameters" when determining whether two "constructors" correspond. Destructors also have the same issue.

Start by comparing [namespace.udecl] paragraphs 4 and 11 with [over.match.funcs#general-9] and [basic.scope#scope-4.3], using the A/B constructor example as the test case. Then inspect [class.mem#general-4] for how constructors and destructors are classified. Done means the draft clearly identifies what “as described below” refers to and resolves whether constructors correspond under these rules.