"Green compile_status coexists with a stale play-mode hotload reporting phantom errors"

After a burst of edits that removed or renamed a type member, play_start spews recurring errors like 'SomeType' does not contain a definition for 'RemovedMember' with line numbers that don't match the current source. The editor's authoritative compile_status shows all compilers Success=true with zero errors. Headless dotnet build is also green. The on-disk file has none of the reported lines. The default spawn or affected feature silently fails.

The reported line numbers may shift across editor restarts, catching different stale intermediate states.

The play-mode hotloader compiled an intermediate/cached snapshot from mid-edit — a transient state where the removed member still existed. The editor's authoritative compiler caught up and reports clean, but the play-mode domain is running the stale snapshot. This is distinct from the whole-assembly-stuck case (stale-assembly-hotload) — here the compiler is genuinely up to date; only the play-mode execution domain is behind.

Two ways to tell this apart from a real compile failure:

1. Check timestamps: the offending errors are buffered in read_console with old timestamps. Filter by time and look for the post-recompile success log to confirm the live assembly is current.

2. Force a clean re-read: touch the edited .cs files (or os.utime() in a script) to bump their mtime, wait ~8–12 seconds for the IsBuilding cycle to complete, re-check compile_status, then restart Play. The stale errors stop and the feature works.

Corollary: deleting compiled _c assets (sounds, models) out from under a live editor emits one-time Detected Asset File Deleted + Cannot recompile: Source file not present + ERROR_FILEOPEN warnings as the watcher drops them from the index. These self-heal on the next boot — not a regression.

The editor runs multiple compilation pipelines — the authoritative incremental compiler and the play-mode hotload domain's own code snapshot. After a burst of rapid edits, these can desynchronize: the compiler settles on the final correct state, but the play domain may have captured a transient intermediate. A forced mtime bump triggers a fresh compilation cycle that resynchronizes both paths.