It's a personal taste thing, honestly. Language features aren't free to users: as a user, you need to understand the behavior, so if there are two possible behaviors that's something else to learn.
There are two different use cases here: lambdas (which may be true closures) and user-defined control constructs. In the first case, I'd argue that you want the declaration semantics to be as close as possible to a normal function definition. You should be defining a function, so return returns from that function, and break/continue statements can't have targets outside the function. For control constructs, you want the code to appear as if its inline, so you want non-local return semantics. I.e. you want it to behave as if it's not actually in a separate function at all.
So I think those are two different constructs, and things get confusing when you conflate the two. At the very least if you want to have those two constructs, make them look different enough that users don't confuse them. Java was going to go the wrong way there on their initial closure proposal (the => versus ==> thing) and make things that look like lambdas behave like in-line statements. Ruby kind of goes the other way and makes everything look like a bunch of statements within the body of something else in contexts (like the reduce() method) where what you really want or would expect is a lambda. If I write "return x + y" in the body of my argument to reduce(), I expect that to be the value of the reducer function, not to exit the function that was calling reduce(). But at least in Ruby a block is always a block and always has the same semantics, even if those semantics seem inappropriate for many use cases.
But again, it's personal taste as to which of those, or both, you want to add to a language. In my personal opinion user-defined control statements aren't all that useful and you can fill most of the needs with language-defined control constructs. But it's a tradeoff the language designer has to make, and there's no one right path.
There are two different use cases here: lambdas (which may be true closures) and user-defined control constructs. In the first case, I'd argue that you want the declaration semantics to be as close as possible to a normal function definition. You should be defining a function, so return returns from that function, and break/continue statements can't have targets outside the function. For control constructs, you want the code to appear as if its inline, so you want non-local return semantics. I.e. you want it to behave as if it's not actually in a separate function at all.
So I think those are two different constructs, and things get confusing when you conflate the two. At the very least if you want to have those two constructs, make them look different enough that users don't confuse them. Java was going to go the wrong way there on their initial closure proposal (the => versus ==> thing) and make things that look like lambdas behave like in-line statements. Ruby kind of goes the other way and makes everything look like a bunch of statements within the body of something else in contexts (like the reduce() method) where what you really want or would expect is a lambda. If I write "return x + y" in the body of my argument to reduce(), I expect that to be the value of the reducer function, not to exit the function that was calling reduce(). But at least in Ruby a block is always a block and always has the same semantics, even if those semantics seem inappropriate for many use cases.
But again, it's personal taste as to which of those, or both, you want to add to a language. In my personal opinion user-defined control statements aren't all that useful and you can fill most of the needs with language-defined control constructs. But it's a tradeoff the language designer has to make, and there's no one right path.