Bundled subresource origins.

Following on a conversation in https://chromium-review.googlesource.com/c/chromium/src/+/2226248, I'd like to understand where y'all are coming down on the origins of subresources from unsigned bundles. From conversations with @kinu and team, I'd understood that unsigned packages directly delivered from https://example.com/ would contain resources that all acted as though they were delivered from https://example.com/, and packages whose provenance was indeterminate would be treated as having opaque origins.

The scheme proposed in https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-unsigned-bundles.md#urls-for-bundle-components is quite a bit more complicated, both in terms of parsing, and in meaning. My understanding is that it aims to give a persistent origin to resources in the bundle that's distinct from the entity that delivered the bundle. Can you help me understand the benefits of that model so we can weigh them against the complexity it introduces?

Read the linked Chromium review discussion and the navigation-to-unsigned-bundles explainer, focusing on the proposed URLs for bundle components and their origin semantics. Compare the stated benefits and parsing complexity, then document a clear decision or rationale about which origin model the project should adopt.