Currently the explainer says:

(component
  (type $r (resource (rep i32)))
  (export "r1" (type $r))
  (export "r2" (type $r))
)

is assigned the type:

(component
  (export "r1" (type (sub resource)))
  (export "r2" (type (sub resource)))
)

In the initial implementation of resources at bytecodealliance/wasm-tools#966, however, I found it more natural to assign this component the type:

(component
  (export $r1 "r1" (type (sub resource)))
  (export "r2" (type (eq $r1)))
)

Otherwise introducing a fresh abstract type which internally is a private alias isn't used anywhere else currently (at least in the wasm-tools implementation). Given this it is a large-ish separate feature to implement the semantics of internally having the same type but externally having different types. In talking with @lukewagner I ended up realizing that the wasm-tools implementation of type ascription is probably not "spec compliant" in that I believe the spec interprets it in a similar manner where internally the item is not typed with the ascribed type but externally it is typed with the ascribed type.

Orthogonal to the limitations of wasm-tools and type ascription, however, one way to recover this functionality could be to perhaps say:

(component
  (type $r (resource (rep i32)))
  (export "r1" (type $r))
  (export "r2" (type $r) (type (sub resource)))
)

generates two distinct types externally via type ascription. This can't be easily implemented in wasm-tools today due to the inability to create these sorts of private aliases, but it's possibly a way to recover the intended original semantics using preexisting constructs.