[Voted into the WP at the March, 2011 meeting as paper N3283.]

Additional note (November, 2010):

The overall treatment of dependent base classes in handling a qualified-id in which the nested-name-specifier names the current instantiation or in a member access expression where the object expression is *this is not very clear. It would be helpful if the resolution of this issue could clarify the overall treatment while dealing with the mixed dependent/non-dependent case given in the example.

Notes from the November, 2010 meeting:

The CWG agreed that if a name is found in a non-dependent base, the type should be treated as non-dependent also.

13.8.3.2 [temp.dep.type] paragraph 4 treats unqualified-ids and qualified-ids in which the nested-name-specifier refers to the current instantiation as equivalent. However, the lookups associated with these two id-expressions are different in the presence of dependent base classes (13.8.3 [temp.dep] paragraph 3) : with an unqualified-id, a dependent base class scope is never examined, while with a qualified-id it is. The current wording does not specify how an example like the following is to be handled:

  template<typename T> struct B {};
  struct C { typedef int type; };

  template<typename T>
  struct A : B<T>, C {
    template<typename U> type a(); // #1
    template<typename U> typename A<T>::type a(); // #2: different from #1?
  };

  template<typename T> template<typename U> typename A<T>::type
    A<T>::a() { ... } // defines #1 or #2?

There seem to be two possible strategies for the handling of typename A<T>::type:

1. It is handled like the unqualified-id case, looking only in non-dependent base classes and not being a dependent type.

2. Since the current instantiation has dependent base classes, it is handled as a dependent type.

EDG seems to be doing the former, g++ the latter.