> IMHO, this violates the idea of scope encapsulation. The inner loop/scope should not know or care what the outer loop/scope is doing nor why. And vise-versa. Just because you can does not mean you should.

If you take this logic to the extreme, you should not be allowed to write:
> if (...) {
> break;
> }

The scope inside of the if statement should not care about the
surrounding loop, so break should be ill-formed here, right?
Obviously, this is a cartoonish take, but what about:

> switch (c) {
> case ' ': break outer;
> default: count++;
> }

If breaking a loop from inside an if statement is totally fine and
doesn't violate this strict notion of "scope containment", then why
would it not be okay to break a loop from inside a switch? Switches
and if statements do very similar things.

Another thing to consider is that many loops (and this is a common use
case for break/continue outer) is that many loops are "closely tied".
For example:
> outer: for (int y = 0; y < height; ++y)
> for (int x = 0; x < width; ++x)

While this is technically two loops, it's really just a way of
iterating over say, all pixels in a buffer, and so an action such as
"break" or "continue" can be applied to both loops, reasonably. I
don't see anything wrong with this; these two loops are spiritually
one loop over all positions anyway.

Furthermore, if "break outer" is wrong, then what do you think about
"return" inside a loop? Return can also escape arbitrarily many loops
at the same time. Is that a wrong thing to do?

> 'Break' breaks out of the scope and goes to after the _end_ of this scope.
> 'Continue' stays in the loop, continuing with for the next iteration of the scope, from the the _top_ of this scope.

The proposal doesn't change that; that's still exactly how it works.
The only difference is that the "continue" and "break" don't have to
apply to the innermost surrounding scope, but you can e.g. target the
for loop enclosing the switch where you break. Philosophically, we are
still targeting "this scope", we're just free to make "this scope" a
bit broader.

Fwiw, you're not the first person to allege that "break label" will
lead to spaghetti. However, I don't see any empirical evidence to back
this up, and I have never seen a style guide for a language with this
feature that would disallow breaks with labels. Also, I encourage you
to come up with a way to rewrite the motivating example in the draft
without use of "continue process_files". Or do you think the
motivating example is actually fine, and the use of "continue
process_files" does NOT lead to spaghetti?