At present, Groovy continues the Java and C++ tradition of treating classes as non-objects. This tradition is evidenced by the operators "new" and "instanceof", both of which imply that classes are not objects.
Of these, "new" is the most heinous crime against dynamic typing (not to mention good OO design), as it forces the specific type returned to be the general type requested. Further, it makes the caller responsible for allocation policies about which the class may have better ideas.
I think Groovy needs to implement a real OO allocation system, accessed by static methods. A default implementation of new() would be provided on Object, but if new() was defined explicitly, we would respect whatever visibility marker was specified. (This will all require some behind-the-scenes trickery, of course.) We would then eliminate the "new" keyword entirely.
This is a significant break with Java, for sure. But it simplifies the conceptual model of the language by making allocation just another operation, and by helping to move classes up to first-class objects. It also eliminates an entire series of constructs from the language. It would require that all classes be named (anonymous classes would go away in favour of named method-local classes), but this would only further simplify the language, as it means that all classes would be defined the same way, regardless of location.
There are some rough spots, of course. Visibility on constructors would be hard to enforce if all construction is done from within the class (ie. by new()), for instance. Also, the means by which a user-defined new() gets the allocation done on its behalf will likely involve compiler-supplied routines, or direct use of the reflection APIs.
But perhaps the biggest problem for this change (and quite likely its killer) will be community acceptance. A lack thereof. As much as it simplifies the language, it's not Java. At the very least, I would like to see us implement James's plan of allowing the "new" operator to be overloaded at the class level, so that we at least gain the benefits of decoupling allocation policy from the request.
– Chris Poirier