Evolving packages over time

I have a wit package that I am evolving over time with some interfaces changing and others staying the same. I'm running into an issue where a world definition for the new package version is a mishmash of interfaces, types, and functions from multiple versions of the package.

Let's imagine two versions of the same wit package (I've elided interface definitions for brevity; hopefully it's still easy to understand):

Version 1

package acme:widget@1.0.0

world host {
  import foo
  import bar
  export baz
}

Let's imagine a version 2.0.0 where only interface foo has changed. The other two interfaces are structurally identical between versions. I have a few choices how to model this.

Version 2 Alternative 1

I can directly reference the old version so that the id of the interfaces does not change at all:

package acme:widget@2.0.0

world host {
  import foo
  import acme:widget/bar@1.0.0
  export acme:widget/baz@1.0.0
}

This has the advantage of directly modeling reality. The bar and baz interfaces are not only structurally identical, they are literally the same interfaces in both packages. Hosts and guests only need to change their understanding of the foo interface, everything else remains the same.

This has some disadvantage, however. The user is now targeting interfaces across multiple package versions even though logically the world is associated with package version 2.0.0. This might become confusing to users who are unsure why they need to target different versions of interfaces.

Version 2 Alternative 2

Alternatively, I can copy all the interface definitions over to 2.0.0 and require users of the world to update to target interfaces with new names:

package acme:widget@2.0.0

world host {
  import foo
  import bar
  export baz
}

This has the advantage of a being a tidy world.

However, hosts and guests will have to update since the names of the interfaces have changed even if they logically are the same. For guests this should hopefully be little change (though wit-bindgen for Rust does encode the version in the Rust modules it generates, so it's not completely without change).

This gets really interesting with hosts that want to support both versions of acme:widget. They will have to have host implementations for all interfaces even those that are structurally identical.

Question

So what is the right path forward here? Which of the alternatives do we want to encourage folks to choose? Is there something the component model can do to ease the path forward?

One possible solution might be to allow aliasing interfaces. If tooling were made aware that acme:widget/bar@1.0.0 and acme:widget/bar@2.0.0 are supposed to be the exact same interface, we could generate code on behalf of the user so that host implementations don't need two different implementations.

However, perhaps the component model doesn't need to change at all here, and we just need to update tooling so that it can be aware of when interfaces are structurally identical so that host and guest implementations can be shared across them.

The issue names WIT package and world definitions, the Component Model, and wit-bindgen for Rust, but no repository file or test. Start by reviewing the package-version and interface-identity rules and existing tooling behavior; done means a documented decision on reusing versioned interfaces, copying them, or adding aliasing support.