That's a good point :O
This should be really solved in a predictable way, otherwise big problems will occur later. I wonder about the solution too, it is really a tricky situation. When a class adds a new method conflicting with an extension, it is a problem if members are preferred. When there are both a member method and an extensions and extensions are preferred, then a problem occurs when the extension is removed. Both problems are basically the same: in both cases the behaviour probably changes a bit and it can break the client code.
But there might be a way. Firstly, I think that any solution should assume version information in the source. (If there is no other reason, then the problem is Java/JVM world still struggles with versioning on that level.) A library implementing an extension should rather declare which versions of the extended library the extension implementation may depend on; the rest can be left to the common dependency resolution tools (like Maven, Ivy etc.).
Secondly, while it looks more natural to prefer member methods over extensions, it might be in the other way. The first reason is that the developer might have means to tell which extensions methods should be available, while it can hardly suppress the visibility of a method of an imported class. The second reason is then the fact that removing a method is much rarer and it implies incompatible version change, while adding a method does not. Hence unexpected removal of an extension method should manifest itself quite early and in a hard way (either the dependecy resolution tool or the compiler complains that something is wrong and does not allow to proceed).
If such an approach should work, then the developer must have means to tell which extensions the compiler may use in a scope. So if it is possible to tell import me extension X for class Y from Z (wildcards on own risk), it is safe: the developer knows that an extension is used if possible (and gets an error if the import is invalid). However, to prevent import polution, it would be really useful to have scoped imports, i.e. imports could be not only at the top of the file, but in any block and visible only in the limited scope (similar to local variables). This is known in Python and I really like it
OK, maybe it is not as elegant and requires that a developer must write something more (or the IDE must offer and handle it for him/her), but the source code is not ambiguous then and the applicable symbol set is more explicit. And maybe it is not a good idea, but perhaps it helps to find some better one