The defect

The version belonged to a package's identity in one place and not in another. merge_conditional_xlings deduplicated by PACKAGE, so xim:glibc and xim:glibc@2.40 were one entry; graph_xlings_split compared whole address STRINGS, so the same two were two packages.

A project pinning xim:cuda-nvcc@13.3.33 while a rule package declared @>=12.9.86 therefore installed both — several gigabytes each — and fillXpkgDirs (keep the first value for a name) answered xpkg_dir with one of them. Installed twice, answered once, and nothing said so.

The rule

A package's identity is (namespace, name). The version is always a constraint on it.

Two steps decide which version:

• Adjudication — the declaration nearer the artifact wins (project > dependency). A declaration naming no version abstains: it says the package is wanted and nothing about which version. Disagreements are reported (xlings/version-override).
• Validation — the winner must satisfy every requirement that lost. >=, ^, ~ and comma-combined forms are requirements; a bare version is a choice, adjudicated rather than refused. Without that asymmetry every dependency that pinned a tool the project also pins would become a hard failure on upgrade.

This is a comparison, not a search. The version is chosen by adjudication and then checked, so the engine never asks the index which versions exist and carries no constraint solver. The cost is stated in docs/05 rather than hidden: a combination a solver could satisfy is refused instead, and the refusal names the way out.

xpkg_dir now answers a range

The version position has accepted ranges all along and xlings resolves one when it installs — but this lookup compared the whole position against a directory name, so >=8.5.0 installed a payload and then reported that nothing was installed. That is the gap that made a rule package unable to state a floor, and the reason every project repeated its rule's package list.

What it enables

[build-dependencies.mcpp]
plugins = { version = "0.2.4", features = ["rules-cuda"], host-module = true }

and nothing else. The follow-up in mcpp-plugins moves each rule's payloads into [target.'cfg(accelerator = ...)'.feature-xlings.rules-*]; this PR is the engine half that makes overriding one of them safe rather than a second install.

Also here

• Four refusals get tokens in docs/11: device-source-unconsumed, accel-backend-undeclared, host-module-missing, tool-version-conflict. The first three shipped in 2026.9.6.5 without one.
• The xlings pin moves 2026.8.30.2 → 2026.9.5.1 (check_version_pins.sh is the guard).
• docs/specs/manifest-semantics.md §4.3.1 said selectors may not name accelerator; 2026.9.6.5 accepts it. Rewritten around the schedule, which is what the split has always been about.
• examples/09-heterogeneous/{hip,sycl} declare cuda in [package] accelerators, which their globs name. Both are skipped by this repo's example job, so only the plugins CI could have caught it.

Criteria

627, 628, 629 and 630 were run against the released 2026.9.6.5 and are red there.