well, that is wrong. Groovy does not simply turn it into a method call. It might result in that method call, but there is a major difference between these. First Groovy asks for that property in the MetaClass, and in this case a property is returned, which means its setter method is called. that means that normally no Groovy standard method call would happen here. Allowing overloaded setters currently means, that we have to do a full method selection each time the property is called. Additionally the information stored in the MetaProperty becomes simply wrong then, because it contains only one method, not both. Maybe you don't remember that by changing the information in the MetaProperty you can turn x.duration =y into x.foo(y).... meaning you could have a setter of any name... and not only that, you can even change the object, that is used to make the call on. While I think the last is not supported by the bean spec, I think the usage of other methods as setter (or getter) is supported by providing a bean info class.

properties are not method calls. They are different in definition and their path in the MOP is different.

With my Java beans oriented head on I still see it like a problem, because the classes used to access the beans don't expect such things from you and may select a random setter.

for 2.0, yes.. only the ability to use exactly one setter for a property might be lost with this.