It could be garbage collected if the scope of the variable was more precisely analyzed (not just "lexically" where you may want to reuse its value by adding code within that scope, but by effective area of use in that lexical scope).
Of course, got it!
Actually I like that there is no optimization: it makes Lua light while giving the programmer more control on what is going on under the hood.
These optimizations do not remove any control from the programmer.
The limits are just the time or ressources needed by the compiler to do its job: a compiler for interactive use will need to run fast, but even on a small device, a program could be extremely optimzied by runbing the compiler on another solid device providing the optimzied code for it, or this could be done by an "installer" process, that will make all the necessary optimizations before the program can be used (this is what happens in DotNet or on Android for newly installed apps, or each time you upgrade Android or Windows with a new VM version that can cointain a new compiler version performing more optimizations or more safety checks; the installer can work on source Lua scripts to generate bytecode that will be run interactively either by a bytecode interpret, or by running it via a JIT compiler to transform it into native code, that can be cached and later executed directly without needing any prior compilation and big resources to run it interactively with fast response time). The same could be done with Lua.
Static analysis can be done at any time, it is cacheable to avoid runtime overhead. It can be redone when needed for specific environments like debuggers/tracers that may need additional metadata not generated by a normal precompiler for normal execution without any compiler. The precompilation in cache can also be disabeld at runtime, by allowing a debugger to plug into a running program, save its state, prepare the necessary metadata for tracing, and then continue running the program with the new controled environment from the restored state before the breakpoint.
The same host platfom can host several kinds of compilers for specific needs of use of the programs (provided as source code or even as bytecode only; and with native code there is also some support for debuggers like with GCC and its debugging info or with MS Visual C/C++/C# and its .pdb debug info files which can also exist for tracing into the OS kernel!). In all these cases, the same promises of the initial programming language can be honored, as long as the debug info are kept and in a suitable format that allows such tracing at different levels: source code if available, byte code, or native code, possibly also with help of reflection APIs from the runtime VM engine (for getting accurate info of the dynamic behaviors).
Of course if all you have is a small implementation of Lua with a single engine containing a single compiler and no usabel reflection and no way to cache the statis analysis, all packed into a small package of a few kilobytes, and no way to feed your Lua engine with bytecode, native code or metadata generated externally, you won't benefit of these optimizations on your small device (notably because such optimizations are lengthy to compute or would need more memory resources that what the local host can grant to the compiler; the same applies to any other language like Java, C/C++, C#, _javascript_, Perl, Python, VB, or device emulators supporting other "native" instructions sets inside a VM, or even OpenCL kernels, and OpenGL renderers, or PostScript, or PDF renderers, which also include their own compilers with more or less optimizations...).
