As for interpreter vs. compiler, I thought about this. One approach is to build a simple VM-based system with the entire language infrastructure in place (fundamental types, minimal standard library), which is not much harder than to write an interpreter with the same infrastructure. Then start fine-tuning the VM itself and possibly thinking about the JIC. The original compiler code, which is not the biggest part of your system, is left almost intact in this case.
As opposed to the "interpreter - first" approach, where you will be throwing away some significant portions of your code once you start writing the real compiler. I thought it would be a waste of time. Interpreters and compilers are too different in almost every respect.
x = 1
y = 2
x = 1; y = 2
x = 1 y = 2
I actually don't mind this. I've never encountered a situation where this style makes the meaning of the code undecidable.
You can definitely improve upon it, though -- the syntax for anonymous functions is a bit cumbersome, in particular. The Lua syntax was deliberately kept tiny to reduce the memory footprint on embedded systems, so some things like switch/case statements are missing, but your language likely won't have the same constraint.
Also, you might want to get an interpreter working 100% first before writing the compiler, as it will be easier to make changes to smooth out emergent quirks in the language. Just a suggestion.