IReadYourCode
This beats Ceylon by factor two (4,189 results) and is close to Kotlin (12,233 result).
Wikipedia has a nice list of key combinations for each OS/language/keyboard: http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_a...
Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations.
Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.
Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it.
Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?>
Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.
If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace.
If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.
During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.
Because Xtend is statically typed, the Eclipse Xtend editor has quite an excellent autocomplete. For your cursors's location it can propose you a list of all valid keyword, methods names, filed names, local variable names, Class names, etc.
And by excellent I mean: Autocompletion will not forget things and it won't show invalid proposals. No guessing!
For Groovy this just isn't possible because it is mostly unknown to the editor which methods and fields an object has. It's only known at runtime.