The dangling else "problem" is a fine example of how novice programmers know better than the language designers. Usually an unattributed story is added, of some PL/I compiler that actually depended on indentation rather than on the language definition to decide the issue.
There is, in fact, a minor problem in parsing a dangling else. yacc and friends will say that a "shift/reduce conflict" has been resolved. The standard way to resolve it actually DTRT, and the else matches the inner if.
The solution to the programmer's "dangling else" problem (as opposed to the compiler writer's "dangling else" non-problem) is to use an editor which does (correct) indentation for you, like (X)Emacs. That way, the indentation of a line depends only on the syntax, and cannot be wrong.
There are many similar "problems":
- The "wrong operator" problem
- Writing "+" when you meant to write "-". This can cause infinite loops and actual errors in code. The solution is never to use the "+" token in your code, only "-". Obviously it would not be possible only to use the "+" token.
- The "wrong function" problem
- Writing "scanf" when you meant to write "printf". This not only prevents your program from running, it even crashes it! (Well, any half-modern compiler manages to warn your program is completely wrong, but that's besides the point.)
- The "dangling semicolon" problem
- Writing ";" in the wrong place, e.g.
for(i=10;i>0;i--);
printf("i = %d\n",11-i);
prints only a single, wrong, value, instead of 10 correct ones. The solution is to use BASIC, which doesn't use semicolons. Or assembler or LISP, which tend to treat them as comments.