if math.random() ~= 0.1 then
local finished = true
Adding "continue" would not add any problem that adding "goto" did not already introduce.
That code gives unpredictable result: what is the value of the "finished" variable when jumping to the ::continue:: label from a "goto" statement where that "finished" variable was not even in scope, and so has no initial value and was still not initialized?
That "goto" statement jumps into an inner scope, so even the validity of the "goto" itself is questionable (and in my opinion it should be invalid too: "goto" is a bad statement here and I don't see any valid use of any "continue" statement or jump from inside any "repeat..until" loop, where only a "break" or jump to outside is semantically valid).
The following code would also be invalid for the same reason:
Here you can get any output, not just "A 10", or "B 11", but as well "A 0", "A undefined", "A nil', "A (random string)", "B 10"... or even strange crashes caused by assertion checks made in the compiler about initialization states.
That's the major argument against "goto" which should absolutely never be used to jump to labels that are not in the current lexical scope: such use is clearly invalid (tolerated in C because local variables are allocated, but don't necessarily have to be initialized: their declaration is forward, they are "preallocated" on the stack but the initialization may have still not occured
Some C compilers enforce a initialization to binary zero for all local variables at entry of the function, even if there are later some initializers that may set (or reset) them explicitly and individually to 0.