Implementationally, hooking up an extra MIME layer is a lot more cumbersome than it should be. This is theoretically a transient characteristic, but I have the creeping feeling that that will destroy any attempts to use MIME for this purpose regardless.
Xml:id assumes unique identifiers within scope, and with multiple documents that would require a global scope, something that is not standardized and problematic (it'd require either using UUIDs as IDs or keeping track of uniqueness in some other way).
I think a better solution would be to use XLink. Assuming each document has its own canonical link, this is then straightforward:
1. Make sure each XML document within MIME/Multipart container includes <link rel="canonical" href="uri:…"/>
2. Each document in a MIME/Multipart container should refer to other documents using xlink, i.e. unique URL with a part identifying specific fragment using XPath (which can then use xml:id in a local scope).
Now, depending on the client following scenarios are possible:
1. Naïve: Client will perform redundant requests, but will cache documents in containers, resulting in several HTTP(304) responses.
2. Smart: Client will notice that referred documents are contained in a multipart MIME message and will use local versions.
As a bonus, this approach is not dependant on MIME in any way — it will work just as well with, for example, a ZIP archive.