I don't understand what you mean, or maybe you didn't understand my example?

There's definitely no "multiple inheritance lookup" going on here. There is only one outer pointer... and it's the same value regardless (the same outer class instance).

The issue is that it has the wrong type...

A derived inner class is only possible in the context of a derived outer, no? Because an inner class must be initialised within the calling scope of its outer... so an inner is initialised by its outer and received a ref to the outer.

A derived inner can't exist unless either 1: it's derived within the context if the SAME outer, or 2, it's derived within the context of a DERIVED outer. Either way, the base-outer is the same base outer... to super will always have a valid outer.

In the context that a derived inner if defined within a derived outer, then the outer pointer can be re-typed to the derived outer within the context of the derived inner.

From the super, it still sees the outer pointer types as base outer, but the derived outer knows that the outer pointer is the derived outer, so it can be typed appropriately.

There's only one outer pointer here... it's just typed wrong from the derived inner's perspective.

This has nothing to do with multiple inheritance... I'm pretty sure this is just a bug.

I'm not sure your explanation why qualifying with `this` works is correct... the fact is, it does work, but I have a different theory. Since the outer scope is a kind of special sauce, and the super has a reference to the outer scope which is typed for the base outer, that's in the implicit namespace... the derived type comes along, and it has its own reference to the outer, which is typed correctly for the derived outer, and so `this.outer` works, because it has the correct type... but if you omit the explicit scope and fallback to the local namespace, I reckon somehow the super's outer is taking precedence over the more local outer reference, and that's why the outer appears to be typed wrong.

Like you say, this is all internal compiler magic; there's only actually one outer context pointer, and how the compiler types that and incorporates it into the local namespace is kinda magic... I think there's just a bug.