In a phrasing like "the member typedef X names ..." or "the member typedef is T", I think this change makes things worse: We know we can't have a fresh type here, so why use a phrasing that allows this?

I agree the change for aligned_storage, aligned_union is good (it's not talking about a pre-existing type), but it seems borderline editorial. (Although it's probably unobservable whether something is a typedef to something else that cannot otherwise be named or is a new type by itself.)

"Member typedef" is not a defined term, and does not clearly indicate that the member can also be declared using an alias-declaration.

"Nested type" is already used in e.g. [container.insert.return]/1, [move.iterator]/1, [depr.func.adaptor.typedefs]/4, and in these cases the types have to be synonyms for pre-existing types (or specializations of a pre-existing template).

I think "a nested type type that names ..." makes things worse. A typedef names another type, a nested type doesn't necessarily.

does not clearly indicate that the member can also be declared using an alias-declaration

I disagree, since there's no semantic difference between the two. [dcl.typedef] p2 "A typedef-name can also be introduced by an alias-declaration."

"Member typedef" seems clear to me, with the obvious meaning, and we do say "typedef member" in [class.mfct]

I'd rather replace "nested type", when talking about synonyms, from [container.insert.return]/1, [move.iterator]/1, [depr.func.adaptor.typedefs]/4 than go the other way.

So, in the interest of progress, this pull request could go forward if it would only propose change 7b2c0db.

For the rest, I agree that "member typedef" might be viewed as excluding alias-declarations (although the difference is unobservable, so it doesn't matter). What about "The member X is a synonym for the type T." as the uniform standard phrasing?

Feel free to reopen if and when you'd like to address the above issues.