Name lookup: downsides to using unqualified class name inside a class definition / omitting template parameters?

Question

In a recent discussion, the matter came up as to whether or not we should always fully qualify the current class' name in the class definition, and also use explicitly specialized templates when referring to the current template itself. To sum it up:

namespace foo {
    struct Foo {
        doSomething(foo::Foo& other); // arguably good
        doSomething(Foo& other);      // arguably bad
    };
}

template<typename T>
struct Bar {
    doSomething(Bar<T>& other); // arguably good
    doSomething(Bar& other);    // arguably bad
};

Problem is, no one could back up their claims with hard facts, it was merely "the name lookup could go wrong" versus "meh, never had any problem".

In order to settle this: are those two conventions strictly equivalent or can the "bad" one sometimes introduce ambiguities in name lookup? References to the current Standard would be very nice.

Of course, the argument of legibility should not be taken into account, I'm really asking about how a standard-conforming compiler will behave in corner cases. However, known implementation bugs are also welcome.

Answer 1

https://ideone.com/f48mJI

namespace foo {
  namespace foo {
    typedef int Foo;
  }
  struct Foo {
    int m_foo;
    Foo( foo::Foo const& o_foo ):m_foo(o_foo.m_foo) {}
  };
}

int main() {
  ::foo::Foo foo_(::foo::foo::Foo{});
}

In conclusion, Foo.

Answer 2

Certainly in the template case they're identical: The compiler injects something like Bar = Bar<T> into the class definition for you automatically.

Additionally for the first example I don't see any way that Foo could refer to anything other than the most locally nested Foo, in other words the current class.

Functionally speaking the two are equivalent but I'm going to argue that practically speaking they aren't: In each case, the more verbose one seems harder to grok and maintain.