You have the right idea. Think of the package tree as an EA Base Project. Its structure will be used as a staring point for new projects, all of which are required to produce the same set of documents from the same package tree structure. Using the RTF generator, I would include all of the virtual documents in the Base Project package tree. When the Base Project is imported, stripping GUIDs, the new RTF model documents will have all of their links updated to point to the new packages, giving me a cloned project with a cloned set of reports (we have 12 documents right now). I want to be able to create a new set of eaDocX documents that pull their content from a newly cloned base project in the same way. That would include the Element and Matrix Reports.
I like the new reporting from model views feature, but can’t see how I could use it to do this very easily without creating a new set of views for each cloned project package. Some of our documents refer to about 20 packages, so I would hate to break the direct link between package content and document, which is one of the attractive features of eaDocX.
To use your example, what I want is:

1. start with a document which refers to Packages (#1, #2, #3)
2. export those packages, & import them stripping GUIDs to get Packages #4,#5 and #6
3. easily clone the original document to get a new one referring to Packages #4,#5 and #6

RTF does it by treating the «package» attributes of model documents as links within the model, and updating their GUIDs as part of the connector clean-up process during import. (Sparx used to treat the package names as links, which did not work very well). I can think of a couple of ways in which eaDocX could piggy-back on this process: make the «eaDocXDocument» element an extension of the RTF model document, and add all of the links to packages currently stored as GUIDs in the XML as «package» attributes to them. If that element is imported as part of a package tree using the Strip GUIDs option, Sparx will update all of the GUIDs, giving you an element containing a set of named packages with updated GUIDs, and allowing you to build an “update links” function for an eaDocX document. You could also do the same kind of thing by using connectors between an «eaDocXDocument» element and the packages included in the document, although I think that this would be a less elegant solution.
I understand that this is not a simple feature to build, which is why I would be happy to settle for a simple macro allowing me to manually replace one set of GUIDs with another in the document XML for now.