Not saying from knowledge, but I'm almost sure at this point Valkey and Redis still behave the same in MULTI. Maybe in the next releases differences will be introduced, but I think it's too soon for such difference.

I guess your question is regarding standalone server?

Let's distinguish between two concepts used with the same term -

1. Client simply as a connection to the server.
2. Client as a managed connection by some library.

As for connection, yes, if you start multi, all the commands the client connection send are sent as part of the multi. If other connections send commands, they won't be served until the multi ends.
That's what multi is trying to guarantee, some kind of atomic behavior, all happens together and nothing else.

At this point comes the need for management, which is why client libraries exist.
At ValKey-Glide we use multiplexing connection, as the third option mentioned in the prev answer. That means, in simple words, that all the commands you want for the multi will be aggregated and will be sent together. Meaning you have plenty of commands in flight, the multi commands count as one all together, and it lands at the server as one. It's important to emphasize that if you decide to use multi, it means that you want to have a strict order of commands, so it's not supposed to be a friend of multithreading.

So the multiplexer behavior makes sense — you get the best of the resources, but you don't break the logic when you require it. But, as mentioned, if you would like to use blocking commands in the multi, you should have another multiplexer; otherwise, it will stay blocked forever.

Did you mean to ask about multithreaded server?