I don't know whether the change is worth doing, but here is a simple way to do it. Define that a client may send more than one message with the same tag, and in that case servers must process those messages sequentially. This is not very hard to implement on the server side, and the single-threaded servers needn't change at all.
Now to implement the so-called batch RPC, you just send three messages in a row with the same tag: tag Topen fid name mode tag Twrite fid offset data tag Tclunk fid and then wait for three responses to come back. Since the client has complete control over the choice of tags and fids, there is no information in the R messages needed to generate the T messages. The various results are completely distinguishable: on success you get back Ropen, Rwrite, Rclunk, If the Topen fails, then you'll get back Rerror, Rerror (unknown fid), Rclunk. If the Twrite fails you'll get Ropen, Rerror, Rclunk. I have no idea whether this is worth doing. My gut reaction is no, but maybe someone will prove me wrong. My point is only that the protocol need hardly change. Russ
