In various forums, recent discussion about Project Lambda have commented on, and often noted in dismay, the current syntax for lambda expressions in the initial prototype.
"Don't panic!" is advice as valid for work on language evolution as on any other endeavor.
Since syntax is the easiest aspect of a language change to form an opinion on, it is the aspect of language changes most susceptible to bikeshedding.
While syntax is an important component of language changes, it is far from the only important component; the semantics matter too!
Fixation on the syntax of a feature early in its development is premature and counterproductive.
Having a prototype to gain actual experience with the feature is more valuable than continued informed analysis and commentary without working code.
I believe this diagram included in a talk on the Project Coin language change process holds for language changes in Java more generally:
While proposing and commenting can be helpful, the effort required to produce a prototype is disproportionally beneficial and the incremental effort using the prototype has even higher leverage. Experience trumps speculation.
And not all efforts lead to positive results; complaining and obstructing alone are rarely helpful contributions.
Just the engineering needed to fully deliver a language changes involves many coordinated deliverables even without including documentation, samples and user guides.
A consequence of an open style of development is that changes are pushed early, even if not often, and early changes imply the full fit and finish of a final product will of necessity not be present from the beginning.
Long digressions on small issues, syntactical or otherwise, are a distraction from the other work that needs to get done.
True participation in a project means participating in the work of the project.
The work of a language change involves much more than just discussing syntax.
Once a prototype exists, the most helpful contribution is to use the prototype and report experiences using it.