Comment 1:

I'm not sure this is worth fixing.  If you really think it is, then I think the step to
take today would be to add a go vet warning for any ambiguous break or continue
statement.

Comment 2:

I think it is, and go vet should probably warn. It's happened enough time to me (and
others) that it's annoying. It's easy to miss, especially if the algorithm keeps running
anyway (e.g. an early exit that is an optimization).\

Comment 3:

Almost never happened to me. The idea of complaining if there is a potential ambiguity
is interesting though.
Vet maybe, language change meh.

Comment 4 by toddw@google.com:

FYI I don't encounter this alot, but definitely enough times to annoy me.  It's an easy
bug to miss when reviewing code.  Here's an example where I've seen it occur.  We start
with this:
for cond {
  if tag == foo {
    ...
    break // breaks out of for loop
  } else if tag == bar {
    ...
  }
}
Now we re-write it as this:
for cond {
  switch tag {
  case foo:
    ...
    break // doesn't break out of for loop
  case bar:
    ...
  }
}
Here's another example; "break" applies to the innermost "for", "switch" or "select",
while "continue" only applies to the innermost "for".  I'm not proposing any changes to
that; it just highlights my example.  E.g.
for cond {
  switch tag {
  case foo:
    ...
    break // runs moreLogic and runs next loop iteration
  case bar:
    ...
    continue // skips moreLogic and runs next loop iteration
  }
  moreLogic()
}
This is pretty weird, since my intuition for "break" and "continue" is reversed.  I.e.
in a simple for loop, "break" runs fewer or equal lines of code in the loop than
"continue", while it's reversed when you nest a switch or select statement.  Sadly I've
reviewed actual code written like this, and had bugs all over.
Note that the definition of "ambiguity" is kind of complex.  The for loop is the only
valid target for the continue statement, and to me it doesn't seem confusing without the
"break" case.  But once you add the "break" case I find both the "break" and "continue"
cases confusing.  Maybe I'm weird.
FWIW my vote is for go vet warnings, only when there could be more than one valid target
for a break or continue statement.  I also wouldn't mind if the language enforced this,
but don't feel strongly.

This happened to me recently but I don't like writing OUTER: everywhere. Maybe a breakall would be better? I use break enough to not want to have to use a label, although the for + switch/select break is definitely a source of mistakes for me.

I'm going to close this one. It's unlikely to find enough support and it's tedious and verbose in most programs.

Just for the record, if this issue were to find interest after all, instead of labels one could follow the break keyword with the keyword of the statement to be broken; e.g. break for to break the innermost enclosing for statement, etc. The 2nd keyword could be optional.