Defer single-file overlays and retire the roadmap

docs/roadmap/future.md

@@ -102,3 +102,29 @@ string equality must not be presented as semantic equality.
 Keeping `Path` solely as an opaque query/building value remains an alternative.
 No current contract changes or implementation commitment follow from this entry;
 a comparison operation can be added compatibly later.
+
+## 5. Single-file named overlays
+
+Status: deferred. Consider supporting a single `overlays.yml` containing named
+overlay bodies alongside the existing
+[selected-overlay directory convention](../config.md#selected-overlays).
+This would let small applications keep their overlays in one file. Planning was
+tabled because the added semantics outweighed the immediate convenience; the
+draft is preserved at `3e50388:docs/roadmap/overlays.md`.
+
+The draft selected a direct name-to-body mapping, strict peer composition when
+both storage forms contribute to the selected name, and file-level version
+checks using the application's existing rule and mode. These provide a starting
+point for reconsideration, not an implementation commitment.
+
+### Questions to resolve before implementation
+
+- Where should collection controls live: within each named body or at catalog
+  level, and how should that interact with document-root control ownership?
+- How should configured version metadata paths coexist with overlay names,
+  including nested paths and modes that do not check overlay versions?
+- Which semantic checks should apply to unselected bodies?
+- Should `.yaml` also be recognized, and how should multiple matching files
+  interact?
+- How should catalog lookup be enabled without disrupting successful loads that
+  previously ignored an adjacent `overlays.yml`?