feat(core,wkg): resolve multiple versions of the same package

[Aditya1404Sal]

Problem

According to the rules governing wit, there's nothing that actively restricts a scenario in which
a wit world can name more than one version of the same package, say for example when a world exports both

wasmcloud:messaging/handler@0.2.0 and @0.3.0 in the same component (from where I ran into this limitation wasmCloud/wasmCloud#5459)

If there's justification needed as to why this is needed, off the top of my head -- it can help in safe migration
to a new interface rev without a breaking change
or in my use, so that a component can A/B test the new one for regressions
wit-bindgen does support it by producing versioned bindings (I think that's what they're called) messaging0_2_0 and messaging0_3_0 so I don't see why wkg can't have it in the override resolution

back to the problem :

Our wash build command that builds our components has WkgFetcher
which could not resolve the mixed deps and while running the fetch flow, one version was always dropped, and the fetch then failed and cleared the deps/ sub-dir.

Change

The resolver is now keyed by PackageSpec -- a package plus the version requirement it was
requested under. [overrides] keys accept an exact version suffix:

[overrides]
"my:dep@0.1.0" = { path = "../dep-0.1.0/wit" }
"my:dep@0.2.0" = { path = "../dep-0.2.0/wit" }

existing behaviour

A bare key like below

[overrides]
"my:dep" = { path = "../dep-0.1.0/wit" }
"my:second_dep" = { path = "../second-dep/wit" }

will behave exactly as before.

[mkatychev]

Hi @Aditya1404Sal, thanks for the submission.
Before I take a look at the code, could you pare down your PR description? The description is a bit too much context and reads as if an LLM wrote it.

[Aditya1404Sal]

Hi @Aditya1404Sal, thanks for the submission. Before I takr a look at the code, could you pare down your PR description? The description is a bit too much context and reads as if an LLM wrote it.

Sorry for that, this PR description is indeed ai-assisted. I've rewritten it to my taste.

[mkatychev]

According to the rules governing wit, there's nothing that actively restricts a scenario in which
a wit world can name more than one version of the same package

@lukewagner apologies for pinging, just wanted to get your feedback and see if this is something we want to affirm for package distribution.

[macovedj]

Was chatting a bit with @mkatychev. I'm not sure this is desired behavior. First off, in your example, the major version is 0, so the bump from 0.2, to 0.3 should signify a breaking change. I think at the very least we'd probably want to not resolve multiple versions when the change is breaking. But even if not breaking, I think a wit/interface change is meant to be more intentional than just bumping a library. For example, the bump from wasi 0.2 to 0.3 completely changes dependence on wasi:io.

All this said, I do believe that package versions are currently treated as a semver carat, so if a new non breaking version is published, you'll automatically get it, which doesn't feel so far off from the spirit of the PR. I am curious though if you've tried using a file path dependency. It seems like that could potentially meet your needs @Aditya1404Sal without the potential baggage of supporting resolution for multiple package versions.

[mkatychev]

@macovedj, had some discussion with @salmans @vados-cosmonic about it and it feels like this is something we should allow this; more context here: https://github.com/bytecodealliance/meetings//blob/main/SIG-Packaging/2026/2026-08-19.md#multiple-versions-of-the-same-pacakge-as-dependencies-for-one-package

[mkatychev]

Could we reuse the PackageSpec type instead of defining DependencyKey?

wasm-pkg-tools/crates/wasm-pkg-common/src/package.rs

Lines 83 to 86 in bc0ece4

	pub struct PackageSpec {
	pub package: PackageRef,
	pub version: Option<Version>,
	}

[Aditya1404Sal]

Done