Delphi extended RTTI object model

• Type: feature (RTL surface + whatever compiler-side emission it needs)
• Track: B to start — it becomes Track A the moment it needs richer emitted metadata than the compiler already writes, which is likely.
• Status: backlog — filed 2026-09-06 as the named blocker for [[feature-embed-dwscript-rtti]].

Why it exists as a row

feature-embed-dwscript-rtti measured its own premise false and concluded the exposer "is not reachable and will not be until pxx has Delphi extended RTTI". That sentence named no ticket, so the dependency was real and invisible: the ranker saw a prio-40 feature with blocked-by: [].

What is there now

lib/rtl/rtti.pas, 294 lines: TRttiMethod, TRttiProc. No TRttiContext.

The classic API is a different thing that is already done — typinfo.pas carries the FPC accessor surface at parity. Do not confuse the two; the DWScript ticket spent a session's work on the classic half before discovering its target used neither.

The oracle problem, stated up front

fpc 3.2.2 cannot compile dwsRTTIExposer either — it lacks TRttiIndexedProperty, which that unit needs eight times. So the usual tools/fpc_diff_probe.sh route settles only the part FPC implements. Expect to specify from Delphi's semantics and a real consumer, and say so in any claim.

Scope it from a consumer

Not from the documentation. dwsRTTIExposer.pas wants 15 distinct TRtti* classes; a smaller consumer would give a smaller and more defensible first cut.