added a comment - - edited
I probably didn't explain well... We have to decide at compile time what the receiver for the method call will be. Here we have to decide for either the static method call on Utility or the virtual method call on Harness. For Java this is no problem, since Java is static typed and will use those types for method selection anyway. So for Java it is easy to pick a method here. For Groovy it is quite difficult. You can start with the fact that Harness may define such a method at runtime. That is almost impossible to completely implement. Also we do not use the static types, we normally use the runtime types to decide on the method. But the method selection does not take multiple receiver into account. So here the compiler decides, which leads to false results like here. If you have no method shadowing or overloading, there is no issue with the current implementation, which will simply take the Utility methods if the compiler thinks those methods are of use.
So what Groovy does is setting Utility as receiver, since you statically import a method from there, totally ignoring that there is another one in Harness. Now method1() is indeed no allowed method call for method1(int), but if it were method(Integer) then Groovy would have used null for the Integer and the call would have been valid.
The only "solution" I can offer is, that we let the compiler not compile this at all. Would you be satisfied with that?