Complete the user-facing forward OverPy language support contract

[Teakowa]

Parent: #1

Goal

Complete the user-facing forward OverPy language/compiler support contract so the declared OPY -> Workshop surface has no unresolved core-language Partial state.

Context

docs/language-support.md is the canonical human-readable support index for OverPy users. It describes supported source forms and explicit limits in ordinary OverPy terms, while tests and pinned reference comparisons protect the behavior.

Forward OPY -> Workshop completeness is independent from Workshop -> OPY reconstruction. Reconstruction remains a separately scoped capability.

Scope

• Keep docs/language-support.md and its detail pages organized around real OverPy source forms and user-visible capabilities.
• Reconcile forward-language support claims against current code, owner tests, pinned OverPy behavior, and representative workflows.
• Resolve each remaining 🚧 Partial row that represents core OverPy semantics or forward compilation by either:
  • implementing the missing owner behavior; or
  • recording an explicit approved ❌ Unsupported boundary when the behavior is intentionally outside the declared support scope.
• Treat established pinned upstream core behavior as presumptively in scope unless an explicit product/compatibility decision excludes it.
• Preserve structural compiler convergence through pinned reference comparisons and focused regression tests.
• Keep canonical Workshop semantics in workshop-rs; route canonical Workshop gaps there rather than compensating in opy-rs.
• Keep Workshop -> OPY reconstruction separately stated and non-blocking for forward-language completion.
• Keep support documentation human-readable; do not introduce another machine-readable shadow support database.

Non-goals

• Replacing executable tests or reference comparisons with documentation.
• Treating Markdown alone as proof that implementation is correct.
• Reproducing upstream internal architecture or data structures.
• Requiring Workshop -> OPY reconstruction before forward compilation can be declared complete.
• Forcing tooling-only report/API parity to gate the forward language surface when it does not change OPY semantics or generated Workshop behavior.
• Duplicating canonical Workshop semantics owned by workshop-rs.

Acceptance criteria

• docs/language-support.md gives an OverPy user a direct answer for every major forward language/compiler feature area.
• Detailed support pages use real OverPy syntax/names and state limitations in user terms.
• Public support status remains Supported, Partial, or Unsupported; no separate support-state database is required.
• No 🚧 Partial row remains for unresolved core OverPy semantics or forward OPY -> Workshop behavior.
• Tooling-only partial capabilities may remain when they are explicitly outside the forward-language completion contract.
• Every supported forward behavior is protected by the appropriate owner tests and pinned reference/workflow validation.
• Approved unsupported behavior is explicit and does not masquerade as successful compatibility.
• Wright consumes the resulting owner capability without compensating for missing OPY semantics.

Ownership

• OverPy language surface, support contract, and forward compiler behavior: opy-rs.
• Canonical Workshop actions, values, enums, settings, validation, representation, and emission: workshop-rs.
• Wright consumes proven owner capability and must not compensate for missing OPY semantics.

[Teakowa]

PR #327 has landed the user-facing support contract. The remaining forward-language work is now decomposed by root capability:

• Complete core collection mutation and control-flow semantics #328 — collection mutation and control-flow semantics
• Complete the pinned OverPy callable and member-function surface #329 — callable and member-function surface
• Complete OverPy enum, constant, texture, string-entity, and contextual-domain coverage #330 — enum, constant, and contextual-domain coverage
• Complete OverPy translations and custom-game settings support #331 — translations and custom-game settings
• Complete source-visible compiler directives and optimizer behavior #332 — source-visible compiler directives and optimizer behavior

Suggested execution order:

1. Complete core collection mutation and control-flow semantics #328 and Complete OverPy enum, constant, texture, string-entity, and contextual-domain coverage #330 establish remaining core source/control/domain semantics.
2. Complete the pinned OverPy callable and member-function surface #329 and Complete OverPy translations and custom-game settings support #331 complete callable/project-facing language behavior; these may proceed in parallel where owner boundaries do not overlap.
3. Complete source-visible compiler directives and optimizer behavior #332 follows the stable semantic/lowering surface so optimizer and replacement convergence is measured against completed behavior.
4. Re-read docs/language-support.md against executable evidence and close Complete the user-facing forward OverPy language support contract #326 only when no pinned forward-core row remains Partial.
5. Resume Bastion convergence through Use Bastion as a real-project compiler convergence gate #314/Converge Bastion compilation structurally on pinned OverPy #319.

Workshop -> OPY reconstruction remains separate under #254. Compile-metadata parity is not a forward-language completion gate unless a concrete source-visible compatibility dependency is demonstrated.

[Teakowa]

Follow-up owner audit after PR #327 found one additional cross-repository prerequisite and several public-surface omissions:

• workshop-rs#237 now tracks the canonical Workshop locale set required by pinned OverPy 9.7.10.
• Support the full pinned OverPy Workshop output locale set #333 tracks downstream OPY compiler/CLI integration for those output locales.
• Complete the pinned OverPy callable and member-function surface #329 now explicitly includes the pinned built-in macro library, not only ordinary/catalog-backed callables.
• Complete OverPy enum, constant, texture, string-entity, and contextual-domain coverage #330 now includes OverPy-owned constants/textures and named string entities.
• Complete OverPy translations and custom-game settings support #331 now includes the documented external settings "..." / settings.opy.json form.
• Complete source-visible compiler directives and optimizer behavior #332 now explicitly covers the full directive families and keeps OPY replacement/optimizer policy in opy-rs.
• Complete core collection mutation and control-flow semantics #328 now makes clear that mutable dictionaries are not a missing target: pinned OverPy dictionaries are lookup/compile-time constructs rather than standalone mutable objects.

The previously demonstrated Workshop owner gaps around Remove From Array By Value and related canonical operations are already closed in workshop-rs; they are not current blockers for #328. Remaining del / continue / goto work should therefore stay in OPY lowering unless new canonical-boundary evidence proves otherwise.

[Teakowa]

Follow-up from the merged v0.1.50 audit (#348) is now tracked in #350.

A subsequent pinned-reference re-check showed that the temporary workshop-rs#248 issue was based on a false owner-gap interpretation: OverPy 9.7.10 does not support backward named goto; named gotos are resolved only to forward Skip distances, while RULE_START maps to Loop. workshop-rs#248 has therefore been closed as not planned.

Keep #326 open until #350 reconciles the remaining source/check residuals and support rows against fresh differential results.