It would be a rankng system where failures push them down in a list and a client chooses from the top from those that store relevant data when making a transaction or making a query.

Then, when work is performed, the client acknowledges with a signature and this adds to a reward table for this task. The client could refuse to sign but then the Intermediary can refuse to act on requests afterwards. For this, requests have to be signed, and thus the querant is identified.

Yes, I am not sure exactly. I know caching could be done and to get people to run these as public utilities they have to profit from this. But the point of it is in allowing non-full witness nodes to contribute to the network in a useful way. Because the blockchain will grow fast, to ensure availability, there needs to be a way to lower the bar on storage requirements.

The creation of an association graph helps distribute witness threads to avoid the duplication of included transactions in blocks, but the same graph can be analysed to distribute partial storage nodes. The exact set of accounts an Intermediary handles can be assigned by Witnesses based on the consensus map, and this list is published so clients know where they can pull down data without putting load on witnesses.

The pre-confirmation idea maybe is not necessary but more copies of the blockchain means faster synchronisation for setting up witnesses as well as for other intermediaries, same as how bittorrent fans out distribution of file blocks to partial and full caches, including even other Intermediaries downloading.

There is a law of diminishing returns at some point for replication of data for availability purposes, but I think you can agree that at some point the blockchain must get too big for average systems to fully mirror. And witnesses don't have to fuss so much with data distribution and replication, and, I think important, query handling.