You're welcome and thank you for your appreciation!
Yes, I definitely succeeded in making a scripting language that fits its purpose. But yeah, at some point one wants to expand even more. :D
For performance, you cannot really avoid a VM. For games I think the so called phenomenon of amortization solves it. You trade one cost of just-in-time compilation to byte code for your VM, but gain large performance improvements for scripts that run for a longer period of time, which applies to games. The cost of compilation is amortized by the runtime performance improvements. If you want to even go further, you can use ahead-of-time compilation, however this goes with the development cost, as you would always need to recompile before testing. Or you support both ways, JIT for dev/debug and AOT for release builds. :D
The console application is basically just a REPL, which means you can interactively execute script code or enter commands, similar to cmd.exe. It's basically just a user interface. The heavy work happens mostly behind curtains, so to speak. The host application however can also be launched with providing a path to a script to be executed. If that's the case, the REPL is hidden and the host application exits once the script has finished. So, if you want to type in some script commands, you just launch the shell. If you just want to execute a script, you launch the shell with the path to the script - and optionally arguments that can be provided to a script.