The COM_MULTI idea did not fly well with connectors.
I'm not aware of plans to use it on connectors, or to develop anything further with it.
Indeed, everything it can do, is possible without changing the protocol, using pipelining techique that JDBC is already successfully deploying. Or the old good JDBC batching,
The possible (and frankly, tiny) advantage of optimiting TCP traffic, in a manner similar to TCP_DELAY, can already be done using tcp_nodelay=0 setting.
Yet the server code is essentially dead compiled, and deployed. It insignificantly slows down the execution of dispatch_command. by adding extra checks "is_next_command", is_com_multi, is_skip_flush". Also from readability/maintainability point, it would be good to remove the extra (and sometimes tricky, like recursve execution of dispatch_command) code.
It could be source of some very subtle bugs .
MDEV-16308, protocol breakage that affects .NET connector, is possibly caused by COM_MULTI code (proof pending)