Possible resolution (option 2):

Change in 7.6.2.10 [expr.reflect] paragraph 5 as follows:

• ...
• Otherwise, if lookup finds a namespace alias (9.9.3 [namespace.alias]), R represents that an unspecified namespace alias among the lookup results.
• ...
• Otherwise, if lookup finds a type alias A, R represents the underlying entity of A if A was introduced by the declaration of a template parameter; otherwise, R represents A an unspecified type alias among the lookup results.
  [ Example:

    namespace A {
      using T = int;
    }
    namespace B {
      using T = int;
    }
    using namespace A;
    using namespace B;
    auto r = ^^T;       // OK, represents either A::T or B::T
  

  -- end example ]
• ...

Possible resolution (option 1):

Change in 7.6.2.10 [expr.reflect] paragraph 5 as follows:

• ...
• Otherwise, if lookup finds a namespace alias (9.9.3 [namespace.alias]), the lookup shall be unambiguous and R represents that namespace alias.
• ...
• Otherwise, if lookup finds a type alias A, the lookup shall be unambiguous. R represents the underlying entity of A if A was introduced by the declaration of a template parameter; otherwise, R represents A.
  [ Example:

    namespace A {
      using T = int;
    }
    namespace B {
      using T = int;
    }
    using namespace A;
    using namespace B;
    auto r = ^^T;       // error: ambiguous lookup
  

  -- end example ]
• ...

Consider:

  namespace A {
    using T = int;
  }
  namespace B {
    using T = int;
  }
  using namespace A;
  using namespace B;
  T t;                // #1, OK
  auto r = ^^T;       // #2, ???

While 6.1 [basic.pre] paragraph 8 clarifies that #1 is well-formed by considering the underlying type, the treatment of #2 is unclear.