Another possibility is to release your native application (including the MIT-licensed Lua interpreter) under the GPLv2 or GPLv3 with the Classpath exception (quoted below). It is also used in a similar way to your use case, by OpenJDK for running Java applications on top of the OpenJDK JVM.
The Lua apps can be proprietary, and it doesn't matter if they have "intimate communication" with the native application. There is also no requirement to provide the recipient with a way to relink the "independent modules" to the GPL-ed software, after modifying the latter.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from or
based on this library. If you modify this library, you may extend this
exception to your version of the library, but you are not obligated to
do so. If you do not wish to do so, delete this exception statement
from your version.
As for your second question with respect to "Application" and "Library" in the LGPL, I would say "Library" refers to the LGPL-licensed library and all its dependencies, while "Application" refers to any software, possibly an executable or even another library, that makes use of the LGPL-licensed library. The "Application" programmatically depends on the "Library", but the "Library" must not depend on the "Application". The "Application" must not be derived from the "Library", but merely using it.