First, a disclaimer: I've been digging through docs and source code for a while now as I maintain and customize a Moodle instance at work, but there's still a lot about the internals that I don't understand, and it's possible that I'm just missing something obvious here. Please accept my apologies in advance if that's the case, especially if I come across as presumptuous, or critical of a sensible design.
Ok, so, here's the short version:
Looking at the database schema underlying Moodle, it seems that the many:many relationship between courses and module instances via the course_modules table could provide the level of abstraction needed to allow an activity or resource to have instances in more than one course at a time. Let's call this "cloning" an asset. Unlike importing an asset from another course, which creates an independent copy, updates to a cloned asset would affect every instance of it. This would be very useful in situations where assets are frequently remixed into custom courses, where importing can create a maintenance nightmare.
The thing is, there are a bunch of other things in the db schema that seem to negate how useful this could be, and I don't really get why they're there.
Words get cumbersome at this point, so I took some time to put together a gDocs drawing to describe examples of what I'm talking about (no Google account necessary to view), as well as a proposed solution. You will probably need to zoom in to read it properly-- just select View->100% from the menu, or use the magnifying glass tool:
I realize that this would be a huge undertaking, and maybe not enough people besides me care about this feature to make it happen, but if there's a good reason to not even try I'd like to know, in case I decide to mess around with it, and just for the sake of understanding.
Thanks to anyone who can offer suggestions and/or clarifications (btw, I've enabled comments in the doc in case annotating one of the images is easier).