This isn't fully baked, but I wanted to get my thoughts down before I spent a lot of time in rearranging documentation. This idea builds off of Marco's reusability concerns and Braden's Link-with-file-specifier idea for addressing subsets of Bundle content.

I had a couple of rounds of interesting conversations with Marco, where he expressed concern about our ability to encourage people to make reusable content by default (or to easily transition their content into such a form). This would involve extraction at the sub-Unit level, such as an individual problem or video. Such a step is possible in the Content Bundle proposal, but it's a bit awkward. You can pull a sharable piece out into its own Content Bundle, but then you'd have to link to it and continually bump the version of the Sequence bundle link pointing to it as you edited the problem. It's also a little technically awkward because you have problems that can either show up embedded in sequences or as standalone entities.

Reflecting on that, I believe the root issue is that Bundle Versions represent both:

• The grouping of changes from the author's point of view (workflow and versioning).
• The addressable thing for sharing, reuse, and dependency calculation (Links point to Bundle Versions).

But maybe we can tease apart those two aspects. For instance, we could say that a Bundle Version is still the increment of authoring work, but there are separately linkable/addressable Bundle Parts within it. In which case, we could keep Sequence content all in a Bundle for the purposes of working on it. But each problem or video would be more cleanly separated into a Part. Content-type would be determined at the Part level – a Bundle Part representing a problem always looks a certain way, regardless of whether it's in a problem bank Bundle or a sequence Bundle.

Some nice properties:

• Makes search implementation simpler.
• Simplifies moving things in and out of library-like structures.
• Allows common case author workflow to remain straightforward and not require link updates.

Some drawbacks:

• New dimension adds complexity.
  • Possibly different mechanisms for intra vs. inter-Bundle linking (might be a simple way out of this).
  • More ambiguity about what should be a Bundle vs. a Collection.
  • Bundles are immutable, but are Parts? Or can they be removed from one Version to the next? In which case, what kind of life-cycle tracking do we do with Parts, which live entirely within Versions in this setting?
• Unclear how it should be modeled. Separate top level directory spaces with metadata? Naming convention for directories within a Bundle?
• Shifting problems out puts us closer to the undesirable state where the exported serialization format is a mess of pointers, making it difficult for folks with github-like workflows to work with.

I'm not convinced yet that the extra complexity is worth the use case, but I am for it if the data model can be simplified enough.