The proxy mechanism always sends one request and waits for corresponding reply, before sending next request.
Requests from filesystems are sent to disk drivers as IRP, I/O Request Packet.
After some basic checking, such as valid offset, byte range etc, ImDisk put these messages in a queue and mark them with STATUS_PENDING. This means that if caller is doing overlapped/asynchronous I/O, they will get control back almost immediately. They can instead wait for outstanding packets to complete.
The queue is handled by a separate service thread, per device, that runs in System process. It synchronously fetches one queued packet at a time, handles it and marks it as completed, so that kernel I/O manager and caller knows that it is finished. When working with drives backed with image file or memory, this service thread directly reads and writes image file or memory block. In case of proxy, it formats a proxy message, sends it and waits for reply.
This means that it cannot send multiple requests to the proxy. To do so, it would need to be redesigned in a way such that it could have queues/worker threads or similar that handles for requests and replies. It would also need, like you mention, some kind of tag so that it would know later which IRP to complete when a reply arrives. When using shared memory, things would even more complicated. It would practically need a new shared memory buffer each time it handles a packet asynchronously, so that client and server do not overwrite eachother's data. It would also need a different synchronization mechanism between client and server, to tell which of the outstanding buffers to synchronize. Or something like this. However, the idea sounds interesting. If you or someone else goes for implementing something like this, I will do my best to support your efforts.