Ovidiu Predescu continues the discussion on Java Syntactic Extensions: " Instead of proposing just some minor syntactic sugars to the Java syntax, it should try to extend the language in such a way that allows unlimited extensibility of the syntax by means of macros."

I agree with Ovidiu, however I would propose something less dramatic.  We can break up the proposal into 2 issues, how to specify a macro and what can be specified.  The first issue, that is the syntax for defining a macro, is something that will take long debate and experimentation.  That is how should we do code quotes, or pattern matching, what would be the form of the syntax tree and a lot more issues. The implementation details of which will also need to be addressed by a followup on JSR-199 (i.e. Java Compiler API).

However, the second issue, what syntax can be extended, is something we can agree upon fairly quickly.  The JSE allowed a restricted set of syntactic forms that could be modified. These were either of the form name(...)  or clause clause ...  where clause was either name ... ; or name { ... }.  So clearly there needs to be some serious discussion as to what syntax change will be allowed. 

Once we understand what can be change, we have the issue of name space pollution.  I've written about this earlier [see], anytime you introduce a new keyword, you risk breaking older code.    The current proposal for extending the "for" statement circumvents this problem by not choosing to add keywords like "foreach" and "in", however it's at the expense of readability.  We should not have to sacrifice readability to maintain compatibility. Therefore, we do need a namespace mechanism for keywords.

One final thought, most of the interesting Macro examples seem to be syntactic sugar on top of control flow constructs (i.e. foreach, when, using, asserts). The other kind seems to be more like short hand for structure (i.e. enum, property) and short hand for invocation (autoboxing, unqualified constants).  Finally, operator overloading may be another kind of syntax extension. I don't believe JSE addresses autoboxing, unqualified constants or operator overloading.