Per 6.5.2, an AmbiguousName of the form 'foo.bar' is interpreted by disambiguating 'foo', then using the result to interpret 'bar'. In the case that 'foo' is resolved as an ExpressionName:

"Let T be the type of the expression denoted by ExpressionName.

- If the Identifier is the name of a method or field of the type denoted by T, this AmbiguousName is reclassified as an ExpressionName.
- Otherwise, if the Identifier is the name of a member type (§8.5, §9.5) of the type denoted by T, then this AmbiguousName is reclassified as a TypeName.
- Otherwise, a compile-time error occurs."

That is, 'foo.bar' might refer to the class that is a member of a type 'Foo', where some variable 'foo' has type 'Foo'.

This contradicts the grammar in 6.5 and the text in 6.5.5.2, which claim that a TypeName must be qualified by a package name or a TypeName (not an ExpressionName). It also introduces an unusual dependency on type checking ("the type of the expression denoted by ExpressionName") and suggests a language in which arbitrary expressions can appear as parts of types.

There is no need for any of this logic: if the qualifier is an ExpressionName, then the entire name must be an ExpressionName. We can figure out later (6.5.6) what it means.