TeX's diagnostics, said in your terms

xtex compile emits the document, runs the TeX engine on the emitted file, and reports what the engine said — against the file you wrote.

$ xtex compile paper.xtex
error[TEX]: Undefined control sequence
  emitted at build/paper.tex:7
  corresponds to paper.xtex:5:1
  blame: xtex-generated

Line 7 of the emitted file is an \includegraphics the emitter built from a \figure block. The compiler says so rather than handing you an error against bytes you have never seen.

The same run, when the fault is yours:

error[TEX]: Undefined control sequence
  emitted at build/paper.tex:6
  corresponds to paper.xtex:6:1
  blame: author-latex

The message is never rewritten

Undefined control sequence is TeX’s sentence and it arrives unchanged, including its own “at line 5” when it has one — that line is about the emitted file, and editing it would be editing evidence. What ExactTeX adds is the line beside it, and the blame.

The four blame values are in checking.md §9. The one that matters here is unresolved: when no map segment supports an answer, the diagnostic says so rather than naming the nearest one. A compiler that blames you for its own generated bytes gets abandoned after the second time.

What is parsed

Only forms observed from a live engine run:

Form	Example
`error: FILE:LINE: MESSAGE`	`error: paper.tex:3: Undefined control sequence`
`warning: FILE:LINE: MESSAGE`	`warning: paper.tex:5: Overfull \hbox (266.11pt too wide) detected at line 5`

Anything else is printed unchanged and given no location. A log parser that half-understands a message invents a location for it, and a diagnostic pointing at the wrong line is worse than one pointing nowhere. So error: halted on potentially-recoverable error as specified — a real line, belonging to the run rather than to any file — comes through as itself.

Repeated messages are reported once. An engine runs twice to settle references and says everything twice; you do not need to read it twice.

The engine is the project’s choice

tectonic by default, because it needs no installed distribution. Name another in xtex.toml:

[tex]
command = "pdflatex"

ExactTeX does not bundle a TeX engine and does not intend to. It emits LaTeX; something else typesets it, and which something is yours to pin.

Typesetting failures, said about your entity

When a supported failure lands inside something you declared, the compiler names it:

warning[TEX]: table `tab:wide` overflows its line
  TeX said: Overfull \hbox (215.64pt too wide) detected at line 7
  emitted at build/v.tex:7
  corresponds to v.xtex:4:1
  blame: xtex-generated

When it does not, the engine’s own sentence stands:

warning[TEX]: Overfull \hbox (192.54001pt too wide) detected at line 11
  emitted at build/v.tex:11
  corresponds to v.xtex:9:1
  blame: author-latex

Both halves are the feature. Restating requires a map segment and a declared entity enclosing the position. Where either is missing, nothing is named — “something overflows” is worse than a message that at least locates a box.

The five supported shapes

Every one transcribed from a live engine run:

Shape	Said as
`Overfull \hbox (…pt too wide) …`	overflows its line
`Overfull \vbox (…pt too high) …`	overflows its box
`Missing character: There is no X ("65E5) in font …!`	uses a character the font does not have
`LaTeX Warning: Float too large for page by …pt on input line 9.`	is too large for the page

Anything else keeps TeX’s words and gains no entity. An underfull box is a real warning about a real typesetting problem, and it is not in this set, so it is not restated as a claim about your figure.

The raw log is read, not just stderr

Float too large for page never reaches stderr — checked against a live run. A reader taking stderr alone would silently miss the whole class, so xtex compile reads the .log beside the emitted file and prefers the richer record where both exist.