I think the note should be in a numbered paragraph alone. It doesn't fit with the preceding paragraph, which talks about friends, nor does it fit with the next paragraph, which talks about what an elaborated-type-specifier means.

(Thinking out loud, then recording for posterity in case it's useful)
Ah, I take back my "'obviously' belongs to the previous paragraph," even in scare-quotes. I had had friend on the brain, and had been reading Note 2 (which appears sandwiched between p4 about friend declarations and p5 still talking about that same friend declaration) as fundamentally relevant to friend declarations, e.g.

class C {
  int S;
  friend struct S; // OK
};

but I see now that Note 2 could also be read as relevant to struct S memberfunc(); etc.

But if it's not talking about friend declarations, then Note 2 doesn't seem to be reinforcing anything anywhere in this section, then! It's referring to a quirk of name lookup described in [basic.lookup.elab] (as name-dropped in the preceding Note 1)... which means that another plausible fix would be to combine Note 1 and Note 2 into a single Note. So that's what I've done now.

I've also removed the paragraph break between p4 and p5, since both paragraphs appear to be discussing the grammar introduced in p4. The following p6, on the other hand, is back to talking about elaborated-type-specifiers in general rather than the p4 grammar in particular.

Finally, I'm unclear on the meaning of this sentence:

If the identifier or simple-template-id resolves to a class-name or enum-name, the elaborated-type-specifier introduces it into the declaration the same way a simple-type-specifier introduces its type-name ([dcl.type.simple]).

The word "introduce" does not appear with any relevant meaning in [dcl.type.simple]. I don't know what it means. Therefore I don't know if this sentence is indeed talking only about friend declarations (cf. the preceding and following sentences in the same paragraph) or if it's making some broader point about all elaborated-type-specifiers in general, and therefore ought to be pulled down to below the friend-declaration stuff.

No.

p4 is the only paragraph here talking about friends. Note 1 (first sentence) emphasizes a possibly non-obvious consequence of the normative utterance "does not consider scopes that contain the target scope", but that rule is limited to friends.

p5 is not exclusively about friends, but just says that a mention of "struct X" has the same semantics as a mention of plain "X" (that's what "introduces into a declaration" wants to say).

Note 2 is a side effect of elaborated-type-specifier lookup pointed to as the second part of Note 1.

So, please leave p4 alone, except: I would be fine with joining the second sentence of note 1 with note 2, and putting the enlarged note 2 in a numbered paragraph of its own (this is the "name lookup" pointer, essentially).

No.

p4 is the only paragraph here talking about friends. Note 1 (first sentence) emphasizes a possibly non-obvious consequence of the normative utterance "does not consider scopes that contain the target scope", but that rule is limited to friends.

p5 is not exclusively about friends, but just says that a mention of "struct X" has the same semantics as a mention of plain "X" (that's what "introduces into a declaration" wants to say).

Hm. So you're saying that p5's sentence "If the identifier or simple-template-id resolves to..." isn't talking about the most recently mentioned "identifier or simple-template-id" (i.e. the one in the three-line grammar production in p4), but is actually meant to hark back to the four-line grammar production in p1? If we want it to read that way, then I suggest (and propose in the latest update) that it should be amended to "If the identifier or simple-template-id in an elaborated-type-specifier resolves to...".

I see now that Note 3 wants to make a general point, that e.g. using T = int; class T g; and template<class T> struct X { class T m_; }; are ill-formed. Its usage specifically of friend (so soon after p4) is just asking for confusion IMO.

Finally, there's the question of why p5 contains a cross-reference to [dcl.type.simple]. You write:

p5 is not exclusively about friends, but just says that a mention of "struct X" has the same semantics as a mention of plain "X" (that's what "introduces into a declaration" wants to say).

But [dcl.type.simple] doesn't seem to say anything about the semantics of "introducing." This table does talk about "specifying a type" — but if p5 is trying to talk about that, it should say something like "If the identifier or simple-template-id in an elaborated-type-specifier resolves to a class-name, the elaborated-type-specifier introduces it into the declaration specifies the named class type the same way as a simple-type-specifier introduces its consisting of a type-name [with the same spelling?] ([dcl.type.simple])." And then it's not clear to me what analogy the "same way..." subclause is trying to draw: Does "the same way" say something about the mechanism by which or the effect of?

I'm pretty sure that this PR has turned into something above my pay grade either way. I'm updating the PR to more-or-less what you said (plus the extra disambiguators/scope-establishers that I think are needed for clarity) and not proposing any change re "introduces" nor re the example in Note 3. (Nor re changing Note 3 from a "Note" to an "Example.")