A very important development has occurred to the moonjit fork;
https://github.com/moonjit/moonjit/blob/master/README.md

As stated in this thread;
https://twitter.com/siddhesh_p/status/1308594269502885889?s=20 @ siddhesh_p Sep 22
"It ought to generally be easy to revert to the upstream tree since they're both [moonjit and luajit] (AFAIK) on the 2.1.x branch. I'll be happy to help with the transition if needed."

It's clear from #13474 Envoy is not in a position to maintain multiple patches and appropriate level of security reviews against multiple old revisions based on whatever political discussions might be happening elsewhere. For context, the underlying Lua project from PUC-Rio has never seen it necessary to enable their basic makefile for dynamic linking or other linux build gymnastics, it's a truly KISS approach to getting the lua engine together. The various luajit forks each have relatively few or one active maintainers, if that many. But the core luajit fork has accepted a wide range of ports from a wide range of contributors and is the most frequently used upstream, as seen here; http://luajit.org/sponsors.html

I'd concur with Siddhesh that getting any s390 patches (31 or 64 bit compatibility) into luajit 2.1 branch should be a straightforward exercise, one which I don't have the machine access to accomplish anymore myself. I suspect Envoy needs only 64-bit compatibility at this late date, which is much less quirky than the 31 bit model. Since it seems that this deprecated moonjit is needed only for the s390 support introduced in #10265 - it seems unwise for the Envoy maintainers to manage this dependency moving forwards.

I'll offer a PR to detangle windows today from the existing moonjit support and lower the surface area required to maintain both in a short-term, but would encourage anyone with the facilities to review these dependencies and patches on moonjit to find us a path for s390 portability back into envoy's trusted upstream fork.

cc: @mattklein123 @htuch @moderation @iii-i