With regard to the reference to Corda, their documents say the following:
5.4 Attachments and contract bytecodes
Transactions may have a number of attachments, identified by the hash of the
file. Attachments are stored and transmitted separately to transaction data and
are fetched by the standard resolution flow only when the attachment has not
previously been seen before.
https://docs.corda.net/_static/corda-technical-whitepaper.pdf
On https://docs.corda.net/releases/release-M7.0/tutorial-attachments.html, Corda talks about how attachments are being used, with the expectation that the node originating the attachment be able to serve the attachment to any other node, and that the requesting node maintaining a cache of the attachments. The attachment hash is the only content stored in the trasnaction. And it is up to the smart contract to manage it's own access to the attachment.
I don't see how any of that is any different from what has already been described. I've actually been playing with core, horizon, bridge, compliance, federation on a private setup here at home. Most of the work I've been doing has been trying to determine the best way to store information about images and digital documents (content, metadata, audit trails) on a distributed ledger. While I originally thought the ledger was going to be some kind of magical place that would just take whatever I was throwing at it, storing the content in a real content management system with extra metadata on the document to catch the transacation and hash information is more than enough for my needs.
I've been doing content management for government, insurance, shipping and manufacturing clients for about 20 years. I am managing systems that are subject to audit by agencies of multiple goverments. Honestly, most of the systems I've managed there are multiple queries to get a document, the metadata and the audit trail history. And all of these systems have a seperate subsystem for routing documents through whatever business process or use case the document supports. And there are a lot "standard use cases" where it almost doesn't matter what industry you're supporting.
I don't really see a valid use case behind having a user's asset storage wallet have to do the work of constructing an order for someone's store. It sounds like the expectation here is that work of constructing a valid order be pushed into the wallet. And the datastore for the whole thing be moved from the organization running the store, anchor or gateway to the ledger.
Am I mistaken in reading the original intent for the destination sysytem to only have to capture and store the transaction information and then have to go retrieve the information from ledger? Or are you talking about a custom app sitting on a stream from horizon? How many inbound transactions will either of those cases be able to support without some kind of queuing when it has to decrypt or parse the content as well as get to the back end system fulfilling the order or acting on the payload?