A tool like this is sorely needed for LaTeX, and Tectonic is especially intuitive to embed into other applications, but the divergence of XeTeX from pdflatex makes it incompatible with most Overleaf projects. This is just an unfortunate ecosystem gripe, but for most workflows I end up having to reach for latexmk instead for this reason.

Huh? Overleaf supports XeTeX out of the box. The LaTeX project, incidentally has been moving towards requiring LuaTeX as the engine (also supported in Overleaf).

The pdftex engine is pretty much a dead end these days and I would only recommend its use for compiling legacy documents.

That said, the biggest problem is nothing to do with the source code of TeX. The change file mechanism is pretty straightforward and there have been tools for decades to allow application of more than one change file against the source, although with the standardization on web2c in the build process as well as better cross-platform C compilation in 2026 vs 1982, there isn’t the proliferation of platform-dependent change files that there were in the 80s when people were compiling on Pascal compilers that supported different subsets of the language.

But as I was saying before I got into that digression, the source language isn’t the issue with TeX so much as the basic architecture which is highly coupled to the limitations of computers in the late 70s/early 80s when even 7-bit ASCII couldn’t be assumed to be consistent between systems¹. As much as I enjoy writing TeX macros and can do wonderful things with them that most people would consider dark magic, it’s a cursed way to do programming and has no parallel in any other programming paradigm.

⸻

1. The SAIL platform at Stanford where Knuth did the initial work, for example, had ↑ in the code space ASCII designates as ^, and IBM mainframes all used EBCDIC which has the complication of having | and ¦ as two separate characters both of which were typically mapped to | in EBCDIC to ASCII conversions with the reverse conversions arbitrarily choosing one of the two characters so that there was no guarantee that you’d get the expected character in your text file conversion² or your ASCII terminal controller.

2. Which is yet another reason why non-Unix operating systems would have distinct text and binary modes for opening files.