Aside from a short "if" statement, I now no longer think it's sexy to abandon ending notation whether it be braces, elements, etc.
Basically they had
if (x)
then()
if (x)
new_call()
then()
This is something you definitely want to avoid and I personally don't trust myself, after a no-sleep code fixing bender, to remember to add {} around something if I'm editing an if. I'd probably forget.
Again, I'd say shorter does not mean better.
if (x) then();
say "yes" if $condition;
if ($condition) {
say "yes";
$affirmative++;
}if (x)
^~
9 : note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
then();
^~~~
Oh yea, undefined behavior. Do you like using undefined behavior?
It is perfectly acceptable, and in fact considered proper engineering practice, to compile with multiple compilers to take advantage of their warning and static analysis capabilities.
If you have a page with enough elements and nesting going on that indentation doesn't make its structure clear, I find it hard to believe that you'll see </div></div></div> and think "oh yes, I just closed <div class='wombat'>".
A good editor may highlight the region that a </div> covers, and/or show the opening element and/or the "path" to the current element in the status bar.
But, a good editor that understands indented syntax could do the same. It is a fault in code editors that they don't often have good features for navigating around source which uses indenting. This isn't a problem with the syntax.
FWIW, I use SLIM - which is a Jadelike language for Ruby - and I hate having to deal with raw HTML. I find it incredibly hard to navigate, primarily because of the lack of indentation. All too often you think a particular block is contained in some element but it turns out it just looks that way because somebody decided to use indentation whitespace decoratively.