The problem itself has been already remedied by the previous fix,
nonetheless, the example given by the user provides an interesting
case where we can encounter duplicate base classes in practice,
since we are not able to find out result of type(SomeClass) expression
yet.
The exception could happen in this case because we used the same cached
result of MRO linearization twice without defencive copying. Then later,
as a side effect of that, in mroMerge() we deleted one "head" from
several sequences simultaneously, hence the IndexOutOfBoundsException.
Some of the ancestor class-like types may be unresolved. The best we
can do is to put nulls for all the unresolved classes to appropriate
places inside the MRO chain. What we used to do in this case it return
the empty sequence of the ancestors.