As long as Lua is hosted in a standalone C program, there's no problem.
But if Lua is to be embedded in other prgram that cannot be terminated (e.g. inside a server app, where Lua scripts are used only to service client requests), then os.exit() should not terminate the process, should not even terminate the thread, it should just throw an exception that will be caught by a sandboxing environment, that will want to perform some safe cleanup (if it can, before returning normally to the service).
The OS does not terminate and cleanup everything (and using Lua VM in their own standalone process is costly, du to their startup time , even if Lua startup is very reduced compared to other VM engines like _javascript_, a JVM, or PHP).
There are also situations where Lua VM will not even be written in C, but will be running inside another VM managing the memory allocation, its own garbage allocator, its own representation of tables (e.g. in a PHP or _javascript_ host, or DotNet, or Perl, Python...). In such situation os.exit() would but terminate a function call in the other hosting VM. It can still rpovide most of the Lua API (with some restrictions for the "io" and "os" libraries, not necessarily available, but offering other libraries for binding and sandboxing a part of the osting VM: instead of performing file-level I/O, the interface could just work by passing and returning values (the Lua script is then used as a function call with no callback
API
to the host): this use is very safe, and even faster (as well the "debug" library could be replaced by something else, the require() function would not take a filename but a resource name located and loaded from the host VM, which could be using a SQL engine, or a query over network such as a REST API, using a hidden URL and checked usage).
Lua is not limited to just is standalone host running as a process with a POSIX file I/O and a command line. We need to preserve the separation between the language, and the various implementations (Lua in C with its LuaC API is just one of the possibilities, it is not and should not be a required part of the language). As well as a language it could support more "native" datatypes than just "number" and "string", with their own semantics E.g. it could support complex numbers, quaternions, vectors and matrixes as values (not as tables) with some coercion defined with numbers (independantly of the precision which is also another goal, which could be transparent if Lua is hosted for example in Mathlab), other string types (ECMAScript strings, i.e. with 16-bit code units, UTF-32 strings), distinctive symbolic values (like in Lisp or Postscript) with a specific syntax for their literals, e.g. some constructor prefix and parameters in a table; like U"abc" to create an UTF-32 string, or C{1,2} to create a complex value (1+2i) or numeric constant with arbitrary length (not reduced to the precisions of IEEE doubles). All these native types would be exposed with new names returned by the type(v) function. The implementation may use other internal subtypes as needed.
