Why two ways of resolving conflict in two or more methods

Language Design
1

I am reading the reference and noticed that there seem to be two different syntaxes for resolving a conflict when the compiler cannot know which method to call.

First, there is:

super<A>.foo() and super<B>.foo()

for when a class implementing interfaces A and B which come with a method with the same signature.

Second, there is:

this@C.toString()

to disambiguate calls to the dispatch vs extension receiver in extensions defined as member functions. The same label syntax is used inside an inner class, accessing the superclass of the outer class to call its method:

super@Bar.f()

This seems a bit inconsistent, there are two syntaxes for similar things (choosing the correct type to dispatch the call to). Why not use one, like for instance:

super@A.foo() and super@B.foo()

for the first case described in my question (interfaces with identical method signatures)?

Please note I’m not criticising or complaining, I guess there are good reasons for it, but I’m genuinely interested as to what they might be.

2

I can only guess, maybe someone from the kotlin team can share some insight.

IMO there is a small difference between this@A and super<A>.
Accessing the super class feels a bit like a generic functions call. All options are equally valid, that is to say there is no way for the compiler to decide which is more likely. The compiler tries to infer it from the context, but if it’s not possible (2 options with the same function) the user has to specify it.
this.doSoemthing() on the other hand is well defined, even if there are multiple receivers which implement doSomething. Kotlin will always use the latest receiver. Therefor I would say it’s more like labels (continue@someLabel).