Clarification request: `rtt.canon` for structurally equivalent types

[jakobkummerow]

(Inspired by #128 (comment))

Consider a module defining two structurally equivalent types:

(type $u (struct i32))
(type $v (struct i32))

Should (rtt.canon $u) and (rtt.canon $v) return the same RTT, or two different RTTs?
What if $u and $v are defined in two separate modules?

This impacts e.g. behavior of a check like: (ref.test (struct.new $u (i32.const 42) (rtt.canon $u)) (rtt.canon $v)).

A reason for returning the same RTT is that this appears to be a requirement for allowing cross-module interop to include RTT-involving operations without forcing the modules to agree on who exports and who imports the shared RTT. And behavior within a module should probably be the same as behavior across module boundaries.

A reason for returning different RTTs is that RTTs having nominal semantics was my initial understanding (and, in consequence, is the current behavior of V8's prototype implementation), but on further thought that was probably wrong (at least for rtt.canon) :-)

[RossTate]

Based on the text in the MVP, the answer to #127, and prior discussions, my understanding is that try.canon is supposed to return the same rtt for all types that are equivalent after instantiation of imported types.

I'm now noticing that there's an ambiguity/inconsistency. What should be done when someone asks for the canonical rtt of an imported type that gets instantiated with anyref?

[tlively]

A reason for returning the same RTT is that this appears to be a requirement for allowing cross-module interop to include RTT-involving operations without forcing the modules to agree on who exports and who imports the shared RTT.

Is this a goal we have? I've seen it cited a few times, but @RossTate lists a bunch of reasons why modules will have to agree on who exports and imports shared definitions already in #128 (comment) (2), including that this is a basic assumption for the design of exception tags.