A lot of OOP syntax has that exact problem because you don't use a fully-qualified method name. That's actually an upside of a janky C pseudo-OOP patterns. You have to call a function, that function has one name, one way of being called. So you can usually find all the call sites with grep (modulo macro explanations or something).
I could imagine a syntax that made you specify the protocol at the call site, e.g. for an object Foo that conforms to protocol Bar with method baz, you'd have to write obj->Bar->baz() as opposed to just obj->baz(). Or alternatively, Foo->Bar->baz(obj) if you want to make any given call site discoverable.
Indeed in OOP (or in any kind of indirect call mechanisms, including ones using function pointers in C, right?) you would not find which particular method is being called, but if you are using a nominative type system with OOP, you would at least find which method of which interface is being implemented—and similarly from the call site you would find which interface is being called. So you get a set of functions that may be called, and you would get the precise list of sites they may be called from. And this you get "for free".
In your proposal by stating the name of interface you are calling you do get to see what is being called, and some protocol implementations such as the one in Python/MyPy you can name the protocol of the object you are invoking a method on.
But how about the implementation sites? I was under the impression with protocol based system you would implement a protocol by just having methods of certain names. So the set of functions that may be called would be the set of classes that happen to have a certain set of methods that conform to a protocol, which might or might not be made with the idea that they should be used in the protocol's context. You would need to rely on documentation, which isn't checked by the compiler.
Personally I think protocols are too ad-hoc for general program structure purposes, though they can have their uses. I consider both "class implements these abstract named interfaces" and traits (as in Rust) better.
I could imagine a syntax that made you specify the protocol at the call site, e.g. for an object Foo that conforms to protocol Bar with method baz, you'd have to write obj->Bar->baz() as opposed to just obj->baz(). Or alternatively, Foo->Bar->baz(obj) if you want to make any given call site discoverable.