Which LaTeX engine should a mixed-legacy project standardize on: pdfLaTeX, XeLaTeX, or LuaLaTeX?

Short answer

Standardize on XeLaTeX as the default. When both legacy package compatibility and Unicode/OpenType font support are hard requirements, XeLaTeX is the most defensible choice: it handles UTF-8 input and system OpenType fonts natively via fontspec, while remaining compatible with the large majority of packages written for pdfLaTeX. pdfLaTeX fails the Unicode requirement outright; LuaLaTeX meets it but adds engine-specific behavior that makes it a riskier default for a heterogeneous document set.

1. Why XeLaTeX over the alternatives

pdfLaTeX is the compatibility ceiling but cannot load system fonts or process arbitrary Unicode without workarounds, so it cannot be the single default. Between the two Unicode engines, XeLaTeX behaves more conservatively: its font handling through fontspec is mature, and most classic packages (geometry, booktabs, hyperref, graphicx) work unchanged. LuaLaTeX matches that font capability but replaces more of TeX's internals — its hyphenation and line-breaking can diverge more noticeably from pdfLaTeX output, and some packages behave differently under its Lua-based backend.

Likely, not certain: the research suggests XeLaTeX has the edge in drop-in compatibility, but packages that call pdfTeX primitives directly (certain microtype configurations, font-encoding hacks, low-level output routines) can silently degrade under either Unicode engine. Each legacy package in your set should be tested individually rather than assumed safe. Behavior is also version-sensitive, so pin a TeX Live release across the team.

2. Does LuaLaTeX scripting create lock-in?

Yes, in practice. Documents that depend on Lua callbacks — programmatic node manipulation, custom line-breaking, Lua-driven data injection — have no pdfLaTeX or XeLaTeX equivalent. If collaborators must compile with pdfLaTeX-based journal templates, any Lua-dependent document needs manual conversion or graceful fallbacks. The pragmatic policy: use LuaLaTeX's scripting only in internal tooling documents, keep shared/submittable documents engine-agnostic (XeLaTeX-compatible, no Lua-only packages), and isolate any Lua code behind conditionals such as \ifluatex where fallback behavior exists.

3. Minimal compile checks before migrating a document

1. Create a small probe file exercising your risk points: \usepackage[T1]{fontenc}, \usepackage[utf8]{inputenc}, fontspec with a real OpenType font, and one legacy package you rely on.
2. Compile it with all three engines and capture logs:

   pdflatex -interaction=nonstopmode probe.tex
   xelatex  -interaction=nonstopmode probe.tex
   lualatex -interaction=nonstopmode probe.tex

3. Grep each .log for engine-specific signals: fontspec errors, \"primitive not available\", missing hyphenation pattern warnings, or package patches applied only under one engine.
4. Compare the PDFs visually or with diff-pdf. Differences beyond expected font rendering — shifted line breaks, changed page counts — flag layout-sensitive documents that need re-proofing, which matters for anything with strict page limits.

One missing detail that would change this recommendation: whether any of your legacy packages invoke pdfTeX primitives directly. If several do and cannot be replaced, a dual-engine policy (pdfLaTeX for those documents, XeLaTeX elsewhere) may be safer than a single default.