The paragraph you quoted seems redundant with normative statement elsewhere.
Note dcl.pre p2

Unless otherwise stated, utterances in Clause 9 about components in, of, or contained by a declaration or subcomponent thereof refer only to those components of the declaration that are not nested within scopes nested within the declaration.

As a stretch, this could be interpreted to apply to "enclosing" as well.

Regarding your second issue (about the implicit using-directive), I think this shouldn't have survivied P1787. @opensdh, are you ok with removing "a using-directive ([namespace.udir]) that names the inline namespace is implicitly inserted into the enclosing namespace"?

The paragraph you quoted seems redundant with normative statement elsewhere.
Note dcl.pre p2

Unless otherwise stated, utterances in Clause 9 about components in, of, or contained by a declaration or subcomponent thereof refer only to those components of the declaration that are not nested within scopes nested within the declaration.

As a stretch, this could be interpreted to apply to "enclosing" as well.

I would argue here, [dcl.pre p2] presumably applies to the following example

void fun(int(*ptr)());  

For the sentence: the declarator-id in the function declaration is... Here the declarator-id should be fun rather than ptr because in is restricted by [dcl.pre p2].

I think enclosing might be not limited by [dcl.pre p2]. Because namespace or class always introduces a scope. Such as the sentence: the enclosing class is.... What I want to clarify for the first issue is that these members declared in the enclosed inline namespace could be referred to by which enclosing namespace. Again, in the above example, Namespace A enclosing B which in turn enclosing C. However, the member of C can only be referred to by B rather A, that is B in this case is the outermost enclosing namespace that can refer to the member of the enclosed C, i.e, the boundary is B.

For the first sentence, I'd like to point out that it is vague anyway ("in most respects"). And I think we can fix the sentence by saying " of the innermost enclosing namespace".

For the first sentence, I'd like to point out that it is vague anyway ("in most respects"). And I think we can fix the sentence by saying " of the innermost enclosing namespace".

Maybe, of the innermost enclosing non-inline namespace and these intervening enclosing inline namespaces would be more clear.

namespace G{
    namespace A{   // innermost enclosing non-inline namespace
        inline namespace B{  // intervening inline namespace
            inline namespace C{
                int v;
            }
        }
    }
}
G::A::v = 0; // well-formed
G::A::B::v = 0; // well-formed 
G::v = 0; // ill-formed

The following p7 exactly says that it's transitive, so I don't think we need to say anything special for the multiple-nested-inline namespace case in p6.

The following p7 exactly says that it's transitive, so I don't think we need to say anything special for the multiple-nested-inline namespace case in p6.

Well, but the innermost enclosing non-inline namespace is necessary. Like the above example, B is enclosing the namespace of C but it's inline. So, the relevant rule "as though they were members of ...", the boundary for such an enclosing namespace should be innermost non-inline. which is consistent with [basic.lookup.argdep#4]

Not needed. The innermost enclosing namespace of C is B. Everything that follows is valid and good for B (after all, you can explicitly refer to inline namespaces). But because B is also inline, the rule applies transitively, where A is the enclosing namespace for B. And since you can name C::v as B::v, you can thus also name it as A::v (but not as G::v).

Not needed. The innermost enclosing namespace of C is B. Everything that follows is valid and good for B (after all, you can explicitly refer to inline namespaces). But because B is also inline, the rule applies transitively, where A is the enclosing namespace for B. And since you can name C::v as B::v, you can thus also name it as A::v (but not as G::v).

Ah, it together with p7 states that meaning. That's concise here. 👍

@jensmaurer It seems that [namespace.def#general-6] still exists a similar issue.

Specifically, the inline namespace and its enclosing namespace are both added to the set of associated namespaces used in argument-dependent lookup whenever one of them is, and a using-directive ([namespace.udir]) that names the inline namespace is implicitly inserted into the enclosing namespace as for an unnamed namespace ([namespace.unnamed]).

Which "enclosing namespace" does the emphasized wording refer to? Is it the innermost enclosing namespace or something else? According to the subject in this issue, since these properties are transitive, I think "the enclosing namespace" should refer to "the innermost enclosing namespace".