Track the next-release migration from Windows GNU/MinGW to native MSVC

Target release: the next release. Goal: supported Windows compiler hosts and generated programs use MSVC on amd64 and ARM64, and active Windows build/release/runtime paths no longer require GNU/MinGW.

Audit baseline: [master 3950416e](https://github.com/wavefnd/Wave/commit/3950416efc55cbc5ae7d54535e5a4e8699394ff0), 2026-09-12. This is a migration plan based on current code and existing reports, not a claim that every validation gap is a reproduced compiler bug.

Explicit MSVC targets, COFF linking, and transactional DLL/import-library/PDB publication already exist. Native ARM64 host CRT/message ownership was repaired in #493. Remaining work spans native amd64 host provisioning, reliable SDK/runtime resolution, executable ABI proof, and release independence. Building the compiler with MSVC alone is not completion: the current Windows output default is GNU.

This tracker coordinates focused work; it does not duplicate the original host-build report #292, output-target umbrella #498, or Windows provider umbrella #385. The earlier instruction in #498 to retain GNU applies while prerequisites are being built. The new release goal authorizes a final removal only after the gates below pass.

Difficulty is an estimate of ABI/runtime risk and required expertise, not a severity label. The five very-high tasks involve native executable evidence across calling conventions, startup, stack behavior, or module ownership; some correct code may only need stronger tests. First-contribution tasks have bounded scope and no ABI redesign.

## Progress (2026-09-16)

PR #667 is merged; #612, #613, #614, #627, #628 and #629 are closed. Their implementation checkboxes are complete, while the native execution and release gates below remain outstanding.

Current local work covers #617, #615 and #616, together with the native CI follow-ups exposed by #667 (GNU target selection in MSVC execution regressions and ARM64 SDK hybrid-archive inspection). These three issues remain unchecked until their required native x64/ARM64 execution evidence is available. Packaging #621 stays after implementation and validation; GNU retirement #626 remains the final cutover.

## First contributions

- [x] #627 — Include enabled MSVC targets in existing system-ABI and std-net codegen regressions
- [x] #628 — Add table-driven tests for the MSVC default-library and linker-option builder
- [x] #629 — Include lld-link in the Windows MSVC package tool inventory

## Medium difficulty

- [ ] #620 — Support MSVC linker response files for long and Unicode input paths
- [ ] #622 — Make Windows package dependency inspection fail on missing tools and unreadable PE files
- [ ] #623 — Run the full Windows case suites with explicit native MSVC output targets
- [ ] #624 — Gate MSVC releases on extracted-package execution with a controlled Windows environment
- [ ] #625 — Switch native Windows default Wave output to MSVC after native validation passes

## High difficulty

- [x] #612 — Build the native Windows amd64 compiler with MSVC and a verified LLVM dependency set
- [x] #613 — Resolve a coherent Windows SDK and VC library set for MSVC output targets
- [x] #614 — Validate MSVC COFF objects and archive members before invoking the linker
- [ ] #621 — Stage native MSVC release packages for amd64 and ARM64 without MinGW runtimes
- [ ] #626 — Remove Windows GNU and MinGW support after the MSVC release gates pass

## Very high difficulty

- [x] #615 — Establish executable MSVC x64 C ABI interoperability in both call directions
- [x] #616 — Establish executable Windows ARM64 MSVC C ABI interoperability
- [x] #617 — Validate hosted MSVC startup and generated runtime-helper dependencies
- [ ] #618 — Verify MSVC stack probing and Windows unwind metadata for generated Wave functions
- [ ] #619 — Complete native MSVC DLL loading, C exports and allocator-ownership interoperability

## Reuse existing work

- Native host/output foundations: #292 and #498. Native ARM64 blockers: #608 (psapi library resolution), #609 (compiler stack overflow before executor execution).
- Tooling and failure visibility: #499 (MSVC compiler discovery, good first issue), #575, #579, #581, #610. General case report identity is #462; negative-result correctness is #576/#577. Do not recreate these tickets under new Windows titles.
- Windows filesystem correctness: #523, #524, #525, #527, #528, #529. Windows environment encoding: #526.
- Native process/handle support: #429, #430, #431 and #568, coordinated by #385. Event/IOCP follow-ups: #530 and #534. Retain the already-added #531 executor restart regression; its current native ARM64 compiler blocker is #609.
- Contributor documentation: #401 (target matrix) and #378 (std capability matrix). Update these existing documents/issues as the migration lands; their old target-status statements must be checked against the actual implementation.

Provider gaps are existing Windows correctness work, not evidence that changing the Rust toolchain fixes them. Native MSVC execution must cover the APIs advertised for this release. Broader new platform APIs can remain separate follow-up work when they are not required for that supported surface.

## Order and release gates

1. Land independent first-contribution checks and native host/SDK/dependency foundations. Resolve #608/#609. Keep GNU usable during this stage.
2. Complete native x64/ARM64 ABI, ordinary startup, DLL and large-frame/unwind validation. Extend the full existing case suites to explicit MSVC execution without deleting or duplicating their workloads.
3. Build native MSVC release archives, validate extracted artifacts in controlled Windows environments, and switch the native default only once required execution gates pass.
4. Remove Windows GNU registrations, fallback/discovery code, CI provisioning and package inputs in the final retirement issue. Unsupported old triples get actionable migration errors. Gate release on MSVC-only Windows results.

Exit criteria:

- Both compiler host architectures and generated program architectures are verified as native, and the enabled LLVM backends are explicit.
- Native cases and ABI/runtime checks pass; skipped execution or object-only success does not substitute for required native results.
- The distributed compiler/tools and ordinary generated programs work with the stated Windows prerequisites, with no MinGW payloads or hidden GNU runtime/tool dependencies.
- No silent fallback to GNU occurs, and the active Windows target list/build/release paths are MSVC-only after cutover.
- Preserve non-Windows GNU support and Linux LoongArch64. Preserve meaningful tests by adapting them before removing obsolete harness paths.
- Continue using native Windows OS APIs in std/sys; this migration does not authorize replacing those providers with libc wrappers. Compiler/LLVM CRT dependencies are handled separately from the Wave standard-library API layer.

Each child issue owns an independently reviewable outcome with evidence, completion criteria and dependencies. Implementation progress is tracked above; release cutover remains gated on the required native execution and packaging results.

Start by reading the progress, child-issue list, and release gates in this tracker, then select one explicitly unclaimed child issue with bounded scope, such as #620 or #622. Follow that issue's named files and tests rather than implementing the migration here. Done means the child issue's evidence and completion criteria pass without weakening the required native MSVC, packaging, or GNU-retirement gates.

Written by the indexing model from the issue text.