How resource URL collisions will be handled?

What should happen if there is a URL collision between URLs of resources contained in a bundle? For example, a page may link to 2 cross-origin bundles that contain the same urn:uuid resource (accidentally or maliciously):

<link rel=”webbundle” href=”https://a.com/bundle.wbn”
          resources=”urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6”>
<link rel=”webbundle” href=”https://b.com/bundle.wbn”
          resources=”urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6”>

A page may also link to 2 same-origin bundles can also carry the same http URL:

<link rel=”webbundle” href=”https://a.com/bundle.wbn”
          resources=”https://a.com/foo.js”>
<link rel=”webbundle” href=”https://a.com/bundle2.wbn”
          resources=”https://a.com/foo.js”>

I would expect that if a single page links to 2 bundles with conflicting resource names, then there should be some kind of an error (when loading the bundle? when loading the conflicting resource?). The situation seems more challenging when 2 separate pages link to different bundles that contain the same resource URL - this scenario is especially interesting if these 2 separate pages are hosted in separate renderer processes (so the URL collision may not be obvious within each of the renderer process and may only become a problem from perspective of a network service process where the bundle contents may be hosted).

It seems that when linking a cross-origin bundle, the UUID needs to be coordinated between 1) the bundle contents (served from the bundle origin) and 2) the page elements linking to the bundle resources (with html served from the page origin). Therefore, it might not be practical to generate a random UUID every time a bundle is served, or every time a <link rel="webbundle" element is served. Therefore, a malicious actor may try to serve bundles that collide with known uuid URLs.

No files, tests, or entry points are named. Start by tracing how linked webbundles expose resource URLs across same-origin and cross-origin pages, including the network service case; done means an agreed rule for conflicting resources and UUID coordination, with the rule documented or specified.