Practice.  Nothing but practice.  Keep at it and it gets easier.

For semicolon, comma, etc. those are just rules of the language.  For parens, brackets, braces, etc. eventually you learn to keep a count in your head when reading, even if you don't move character-by-character.

If you don't understand the rules in the first place, spend time on that.  If you do, but it's still a problem, slow yourself down and think about it as you write code, rather than writing as fast as possible and letting the compiler complain.

Finally, note that the compiler won't always complain.  In some languages with some libraries, foo(bar(1), 2) and foo(bar(1, 2)) can both be valid code, but with very different meanings.  This is especially true when you're talking about vector math libs, but in lots of other places as well, for instance in Python with libraries that use default parameters a lot.

@3, I personally prefer putting the brace on the same line as the declaration, just because it filters out unnecessary things and is easier to read for me. But that's my preference.
As for the question itself, I've seen some authors do this in their code -- it may help:

while (cond) {
if (cond) {
// lots of opening braces here
} // if
} // if
} // while
} // for
// ...

This might help you know when things begin and end. In languages like Ada, things like this are required, e.g.:

procedure foo is
begin
if condition then
-- block
end if;
end foo;

@4, I think this is common in java and js. I work with c#, and the convention, at least in my company,  is to put the brace on a single line, so I don't have a choice. It is not so bad though, since I can diferentiate one line if statements from the beginning, without scanning for the end brace.

Opening braces on a line by themselves is a style I've only ever seen used in C, and never before my current job.  Take that as you will.

It's out there, but it's really not the dominant style anymore.

It's also worth adding that if you nest *anything* beyond 3 or 4 levels without a really damned good reason, it's probably bad code.  If your expression is going that deep with the parens, pull part of it out to a variable; if you're going that deep with braces, pull part of it out to a function.

@9
It's possible.  I haven't looked closely at dart.  But you can attach things after the fact I think, and there's always variables.  This is entirely pseudocode, but you could do:

sidebar = [
    button { name = "save" },
    button { name = "load" },
]

main_panel = [
    button { name = "back" },
    button { name = "forward" },
    textField: { label = "input some text" },
]

app =  [
    sidebar,
    main_panel
];

Dart uses normal language constructs for UI.  This means you can build up fragments, return fragments from functions, build fragments in loops, and so on.  In this context, deeper nesting is feasible, but look how I laid out the above.  You can indent the levels and let the indentation count it off, and put only a small bit of the nesting on each line.

I think the actual problem here isn't that you can't handle nesting, it's that you haven't actually learned dart properly.