Measured 2026-09-06, 3e2bca576

var Co: Comp; D: Double;
D := 4.7; Co := D; WriteLn(Co);
{ pxx  5                          }
{ fpc  5.000000000000000000E+0000 }

Same for every row: values agree (5 / 2 / 4 / -5 / -2 / 0 / 2), rendering does not. comp is aliased at pasparser_lval.inc:8114:

else if CaseEqual(nm, 'comp') then Result := tyInt64

so nothing downstream can tell a Comp from an Int64 — including Write.

The fork, stated rather than decided

It may be a bug. A program's observable output differs, on source that compiles under both and that the author meant to write. That is the ordinary definition of a compat defect, and Str/Write/WriteLn are exactly where a type's identity is supposed to show.

It may be known-incompat, chosen. FPC's Comp is a legacy Turbo Pascal artefact — an integer that renders as a float. Someone writing WriteLn(Co) almost certainly wants to see 5, which is what we print; matching fpc here means printing a worse answer to be identical. CLAUDE.md's ceiling is "ask what the source MEANT, not what FPC returned", and what it meant is the number.

What would settle it: real source that wants the scientific rendering — Comp used for its width and formatted for output. Absent that, a probe printing a Comp is not evidence, the same way a program printing SizeOf of an expression is not.

Cost, if it turns out to be worth doing

Not a one-liner. comp would need its own TTypeKind rather than an alias, so that the write path can branch on it, and every site that currently benefits from Comp being Int64 (arithmetic, comparison, the rounding store fixed in 3e2bca576) would need to keep working through the new kind. Ranked 20 because the value is already right and the shape is rare in real code — not because nothing observably differs. Something does, on x86-64, measured.