NoSQL document-based rather than relational-based databases could deal with this. I admit that there are caveats to such an approach. From a high-level look at the idea, it seems that all of these things could be ironed out.
For example, you don't need to separate the text and the images of a document. For the most part, you could just 'store a MS Word document in a DB BLOB.' The idea would be that the DB (or some sort of external indexing) is aware of how to parse the MS Word document so that it can be searched insofar as the text is concerned. It might get more complex if you wanted to have the images tagged as well, (thought there may be a way to have the indexes extract tags from the image metadata, or from the original location that the image was imported into the document from).
Remember that the entire purpose of this is just to do a couple of things:
1. Classify data by type and/or format ('image','PNG','PDF','document')
2. Provide a way of easily accessing that data.
For specific types of data like Photos, you could have a more specific (optimized?) store. For more general types of information you could have a more generalized store. For information where the content has no practical value as far as indexing goes (e.g. SolidWorks files), you could just have a generic metadata attached to the file information (name,description,tagging).
You could have a 'general docs dialog' that does the generic searching by metadata (document name, type, tags, content if index-able).
Then when you open apps you are displayed with the content right in front of you (ala iPhoto). Rather than an empty window that wants you to open content. For example, you open SolidWorks, and it shows you all of your SolidWorks documents with thumbnailed previews.
There could also be defined 'meta-documents' which are just collections of pointers to other documents. You alluded to this in your post, but you were using the idea in the wrong fashion. If you were creating something like an article with embedded images, that would be a document in it's own right. A 'meta-document' would be a collection of disparate type of multimedia in a 'collection' (e.g. taking a bunch of documents -- pdfs, images, etc -- related to a project and stuffing them in a folder or a zip file). [ Though this would depend on the implementation, b/c they could just be implemented as cross-content tags unless you wanted to be able to attach specific meta-data to the meta-document, but not the individual documents ]
As wonderfully complex as all this seems, it could be presented to the user in a simple fashion. The user would have no idea what a meta-document is. They would just know that the open up their scrap-book program and they can create scrapbooks, for example. The underlying implementation of the scrapbook could be a multi-page document, or a meta-document.