docs: the three Windows toolchain axes — a design, and two corrections - #446

The architecture review found where the problems are. This is what to do about them — written after a round of questions that overturned two shapes in my own proposal.

Two corrections, recorded up front (§0.2)

Both are in the doc because the wrong version looked equally reasonable and will otherwise be proposed again:

• Generalising @system to gcc/llvm is backwards. xlings is a user-space OS and mcpp minimises host dependence — msvc@system is a Windows concession, not a capability three families are missing. (Also noted: the one place host dependence genuinely is offered is spelled with no family at all.)
• A windows_sdk = "..." manifest key should not exist. The model already reserves the slot — runtime_binding.cppm:26 documents ucrt@... and nothing populates it — and a version key would sit next to _WIN32_WINNT looking interchangeable while controlling a different thing. That is worse than not having it.

The three axes

Currently entangled; they take values independently — a managed toolset with the machine's SDK is what xrgui's CI does today — so any design fusing them into one switch is wrong.

And the resulting layering:

ucrt        →  SDK gives import libs, OS gives the runtime   →  a floor declaration
vcruntime   →  toolset's own Redist, ships with the artifact →  cxx_runtime
um/shared   →  SDK, link-time only                            →  no runtime counterpart

The ucrt@<ver> identity is deliberately not the same as glibc@<ver>: glibc binds a payload the artifact really runs against; ucrtbase.dll lives in the OS and must not be shipped. That difference goes in the code comment, or someone will try to bundle it.

mcpp pack is deeper than a missing feature

ldd_parse computes the dependency closure by running the binary (LD_TRACE_LOADED_OBJECTS). So it cannot cross an OS or an architecture by construction — the #if defined(_WIN32) refusal is a symptom, not the cause. Reading imports statically is what makes cross-packaging fall out rather than be added.

Also: pack never reads the Contract, so cxx_runtime has no enforcer at packaging time on either platform.

Acceptance criteria none of which CI can satisfy

This round had eleven defect layers and every one of them was green in CI when it shipped. So the criteria are written against that:

• SDK binding: set WindowsSdkDir somewhere else and the build still uses the payload's SDK — if the environment can override it, it was never bound
• runtime: /MD artifact runs on a clean Windows box with no VS and no redist — explicitly a machine poorer than the CI runner
• pack: build a Windows zip from Linux — cross-OS is the whole point; same-OS proves nothing

Two of them require a poorer environment than CI on purpose: "the verification environment is richer than the target" is the shape that produced most of this round's defects.

What is deliberately not done

§2.4 — the manifest SDK version key. Reasons in that section, including how Windows developers actually handle the SDK today and why the default (follow the toolset's dependency) already beats the mainstream practice.