Unity Roslyn REPL v0.7.3

[0.7.3] - 2026-05-12

Changed (Korean README rewritten in natural prose)

• README_kr.md rewritten to read as native Korean rather than as a literal translation of README.md. Removed translationese tics (over-use of "…할 수 있습니다", chained "…됩니다" passive endings, "권장합니다 / 구성되어 있습니다" stiff phrasings, comma-heavy English-style enumerations), broke up multi-clause English sentences into shorter Korean ones, and softened the section headings ("왜 쓰나요?" → "어떤 일을 도와주나요"). Code blocks, menu paths, the helper table, and the meaning of every section are unchanged so the EN / KR pair still describes the same package; only the prose register moved.

Removed (UsingsStore legacy key migration)

• UsingsStore.LegacyKey (RoslynRepl.CustomUsings, the project-agnostic key the pre-Phase-4 builds wrote to) and the MigrateLegacyKeyIfNeeded step that ran on the first LoadCustom / Save after each domain reload are gone. The package shipped publicly at 0.7.2; before that the migration window covered users still upgrading from local 0.7.0 / 0.7.1 builds, but those paths no longer have a real consumer. Carrying the migration forward only added a stateful first-call branch on every load and a tiny _legacyMigrationChecked flag to remember whether we'd already swept the legacy key this session — both dead weight on every fresh install.
• A 0.7.1 install upgraded to 0.7.3 will keep its custom usings (the per-project bucket lookup is unchanged); any value that still sat under the global RoslynRepl.CustomUsings key on first launch of an even older build is no longer rescued. Wipe by hand from EditorPrefs if you need to. Reset Project Data continues to clear the current per-project key.
• Drive-by sweep for similarly-dead compatibility paths: MethodPatchView.OnPullOriginalClicked no longer special-cases the // Supported scope: void instance methods. historic starter text (only the current DefaultBody and its prefix shape are recognised), and a stale "legacy" word in RoslynReplWindow.OnBrowserInstanceChosen's comment was relabelled to "default" so the description matches the live code. The ;-vs-, ParameterTypes fallback in MethodPatchSpec.SplitParamTypes and the folder-mismatch warning in ReplPackagePaths stay — they describe live code paths that are still load-bearing for fresh installs. Closes #53.

Added (Per-row Delete in the Patches list)

• The Patches list now has a per-row Delete button next to Load / Revert. Reset Project Data was previously the only way to drop a draft from the registry — too broad for "I'm done with this one row", since it also wipes snippets, history, watches, and every other Patch the user is mid-debugging. The list section header is renamed from "Active patches" to plain "Patches" (Revert leaves Inactive drafts behind, so the section is no longer "active only"); the empty-state placeholder reads (no patches) accordingly.
• Delete shows a confirm dialog ("Delete this patch draft?") that calls out the destructive payload (the persisted body for that spec disappears) and adds an explicit auto-revert note when the row is currently Active. The handler reverts the Harmony detour first if installed, then calls PatchRegistry.Remove(spec) which persists the removal — so a domain reload won't resurrect a deleted draft. Reset Project Data remains the broad cleanup path. Closes #52.
• PatchPersistence.Save now deletes the on-disk file when the supplied spec list ends up empty after filtering (instead of writing {"version":1,"items":[]} to disk). Without this, deleting the last patch row through the new button left a zero-content file on disk: the Patches UI rendered empty, but HasAny() kept returning true and Reset Project Data fell through the "Nothing to clear" early-return into the stale-file cleanup branch. Centralising the empty case at the persistence layer covers every caller — Remove, Clear-via-registry, AddOrUpdate of a filtered-out spec — without each call site having to remember.
• Save returns bool and propagates the UserSettingsStorage.Delete success flag through PatchRegistry.Persist and a new PatchRegistry.Remove(spec, out bool persistedOk) overload. The per-row Delete handler now distinguishes a clean success ("Deleted: …") from the soft-failure case where in-memory removal worked but patches.json couldn't be deleted (locked / read-only) — a domain reload would otherwise resurrect the supposedly-deleted draft. Partial-failure status surfaces inline with a hint to check the Console for the file path.
• PatchRegistry.Remove now persists before mutating _byKey (build the post-removal snapshot, call Save, only then drop the key from the live dictionary). On a multi-row delete the previous shape mutated first and then wrote — if the write threw on a hard I/O failure (permissions, disk full, atomic-replace contention) the registry was missing a key the file still had, and a domain reload resurrected the supposedly-deleted spec. The Delete UI handler wraps the call in try/catch so the exception surfaces as a "delete failed, list unchanged" status with the underlying error logged to the Console.
• The Delete failure status now branches on whether the row was Active before the click. For an inactive draft "patch list unchanged" is accurate; for an active row the earlier PatchEngine.Revert(spec) already removed the detour and persisted Status = Inactive before the failing Remove ran, so the message instead says "the patch was already reverted (detour removed, row is now Inactive); re-Apply if you want it active again". Without the branch the UI would falsely reassure the user that Play Mode behaviour was unchanged when in fact it was already reverted. PR-review followups on #52.