Yes, 5.3 is not a "minor version" increment, it's a major version increment on 5.2. That's how Lua version numbering works.
Adding support for 5.3's integer subtype is probably going to be a very large project, I would guess that annoyed Mike.
People say that LuaJIT's source is difficult to understand, but I've seen source for several VMs with JIT compilers and this one certainly isn't the gnarliest; it's decently well commented. It only took me 30 min to add a new builtin function, with almost no understanding of the codebase beyond skimming a couple header files. As long as you don't want the JIT compiler to output asm for your language extensions, it's almost friendly.
Parrotting Mike Pall: having 64 bits integers require 128 bits for representing Lua values. This would be bad performance-wise because it would clutter the CPU cache (as it is the case for Lua 5.3 vs 5.2).
Currently, LuaJIT relies on NAN tagging which allows it to represent values in 64 bits.
I noticed that LuaJIT has the LJ_DUALNUM define, which actually internally adds an int32 subtype which causes numbers which can fit in an int32 to be stored as such. It does not change the semantics, it's to avoid floating point ops on (mainly ARM) processors with slow or emulated FPUs.
However, I think it should be possible to extend it without a huge amount of work to implement Lua 5.3 semantics with a 32 bit (rather than the default 64 bit) integer subtype. I think it would still be useful to a lot of people, personally I would love to have it.
Increasing TValues to 128 bits would be very undesirable, but since luajit already supports 64 bit ints through the ffi library I don't see why they couldn't be stored as boxed udatas/cdatas in the same way.
Adding support for 5.3's integer subtype is probably going to be a very large project, I would guess that annoyed Mike.
People say that LuaJIT's source is difficult to understand, but I've seen source for several VMs with JIT compilers and this one certainly isn't the gnarliest; it's decently well commented. It only took me 30 min to add a new builtin function, with almost no understanding of the codebase beyond skimming a couple header files. As long as you don't want the JIT compiler to output asm for your language extensions, it's almost friendly.