Better to use a more established language than reinventing the wheel
https://github.com/raptorjit/raptorjit
Which makes it a very good pick for NeoVim. It basically means that the plugins are basically supported forever without the JIT being a moving target. NeoVim also supports Vimscript as an alternative.
However, I'm hoping to learn more about the internals of the JIT to see if I can take up some of the effort in progressing it. I have a very deep interest in Luajit for some reason. As long as people like me exist, it's not dead.
>almost identical to each other but different enough that a migration is unreasonable.
There's nothing unreasonable, and all versions of Lua mentioned are backwards compatible, so there's not even a problem about migrating. Going to a new version is as simple as installing it and running your program.
Not true. Each minor version of Lua tended to inject incompatibilities that can't be trivially resolved. Lua 5.2 had made a catastrophic change to the environment [1], and Lua 5.3 was less severe but there are subtle issues with integer-number conversions you won't ever want in your large codebase [2]. And that is not a theoretical matter, we had to stick to Lua 5.1 exactly due to the environment changes even though 64-bit integers would have made our codebase much cleaner. And Lua 5.1 and 5.2 are no longer supported [3] (though as you have said, LuaJit may be supported) despite of all remaining issues.
[1] https://www.lua.org/manual/5.2/manual.html#8
But otherwise many codebases do move up Lua versions (outside of LuaJit), it's not a Python 3 "wait 10 years", Perl 6 "Wait 20 years" situation/
Perl 6 requires the full p5 compatibility as far as I recall. It was designed to coexist.
Lua only provides some C preprocessor flags for partial backward compatibility.
I think adoption will remain pretty limited though, because plugin authors want to support vim and neo.
Yes.
> (it can be disabled at build time)
No, Lua is not optional in Neovim.