I really like what Groovy is turning into.  Closures are definitely the
most important thing in my eyes, but I can understand that the value of such a
feature can be puzzling for you until you try a language like Ruby.  I have
also been very impressed by the choice of features that James has made so far
and I agree with pretty much all of them.  Except maybe for
this one.

import java.util.Date;
import java.sql.Date as SqlDate

I have seen "import renaming" at work with Eiffel and it’s not pretty. 
It’s a good example of a feature that sounds good in theory but ends up making
your code very hard to read and to maintain.  Note that Eiffel was worse in
that respect because it also allowed to rename methods when you import them (a
feature that, unfortunately, Ruby supports as well).

What problem are we trying to solve exactly?

Sometimes, you have to create a class that already
exists, either in java.lang or elsewhere.  And before you jump the gun and
say "just make sure it doesn’t happen", you need to realize that you don’t
always have a choice since these classes might have been generated by a tool
that doesn’t allow you to customize its mapping (such as an XML-Java mapping
tool for example).

I would argue that in such a case, it’s much clearer to require the developer
to fully qualify both colliding names in order to clear up the ambiguity:

java.lang.Number n1 = …;
com.foo.Number n2 = …;

instead of using a random renaming which is local to the compilation unit
and can vary depending on who is writing it:

MyNumber n1 = …;   // java.lang or com.foo?  Need to check
the import

I will also observe that in my experience, such cases are rare.  Adding
a feature to a language in order to address a rare case is a dangerous slope
that Groovy should avoid at all costs.

I think Groovy has tremendous potential, which is already showing thanks to
its ability to compile to bytecode directly, hence making it useful to Groovy
fans and non-fans alike.  But Groovy’s biggest challenge still lies ahead
and James and his team will have to be very vigilant that any new feature they
add to it obeys the "80/20" rule:  solve 80% of the problems with 20% of
the work.

Based on what I’ve seen so far, I am confident James is up to the task.