the first one could be valid, if the (reachable) label had some code to execute outside the label itself. But because there's no explicit return statement at that point, it just returns nil (or an empty ordered list of values, which is equivalent). All the question is about which instructions can follow a return in the same block, and abviously an empty statement or no statement at all after an explicit return but before the end of block is functionnaly equivalent :
if the end of block is the main block os a function, it is exactly like if there was two return statements, one explicit and another implicit, the second one (insert implicitly just before "end" being normally unreachable, and eliminated silently by the compiler as it is merged with the previous explicit one).
Now comes the question of empty statements: it's something that the compiler could eliminate siliently as well, not by the syntax itself, but by the fact that there's no code emitted after the code already emited for the explicit return.
But if one wants empty statements there, it should work: the semicolon at end of a return is already optional and generating an empty statement, but nothing syntaxically prevents from generating several empty statements.
That remarks also applies to any statement you put after a goto statement: it can also have an empty statement with the (optional) final semilon.
So after any goto or return, accept any number of mpty statements, and a **reachable** label (independantly of whever that label is then followed or not by other statements, empty or not).
Being a ** reachable** label means that the syntax above points to it, or that any reachable code below (and in scope) includes a backward goto statement to it.
The "reachable" condition cannot be determined by the syntax but by code flow analysis, which should then detect dead code and signal unreachable code (I'm not sure it should be a syntax error, it could just be a warning, because the compielr may elminate that dead code directly, and silently, or would just emit a warning in a compiler with a debug mode (such as in an IDE).
Such dead code may occur because of automatic code generators (e.g. using templates). In C/C++ they just generate warnings if one wants to detect them and has activated the correct warning level in the compiler options. The same could apply to Lua. But then it's no longer to the syntaxic parser to signal them and break which is in fact harmless in most cases
Lua already has some syntaxic "noop" features which is intended for code generators, such as the trailing comma in lists of initilizers for table contructors. I see no reason for not accepting also empty statements with the same goal.
