[Moved to DR at the April, 2013 meeting.]

Proposed resolution (October, 2012):

1. Change 5.10 [lex.name] paragraph 2 as follows:

The identifiers in Table 3 have a special meaning when appearing in a certain context. When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production. Unless otherwise specified, any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.

2. Change Clause 11 [class] paragraph 3 as follows:

If a class is marked with the class-virt-specifier final and it appears as a base-type-specifier in a base-clause (11.7 [class.derived]), the program is ill-formed. Whenever a class-key is followed by a class-head-name, the identifier final, and a colon or left brace, final is interpreted as a class-virt-specifier. [Example:

  struct A;
  struct A final {};      // OK: definition of struct A,
                          // not value-initialization of variable final

  struct X {
   struct C { constexpr operator int() { return 5; } };
   struct B final : C{};  // OK: definition of nested class B,
                          // not declaration of a bit-field member final
  };

—end example]

The ambiguity in an example like

  struct A final { };

is resolved by 5.10 [lex.name] paragraph 2 to be the declaration of a variable named final:

any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.

Similarly, in an example like

  struct C { constexpr operator int() { return 5; } };
  struct A {
   struct B final : C{};
  };

final is taken as the name of a bit-field member rather than as the name of a nested class.