The submission order from clients will not be guaranteed. The server will be responsible for ensuring that entity actions are applied in the intended order.
Here's what we wrote in the Google doc on that subject:
Sequential integer versions are easy to work with but are not guaranteed to be unique across clients and don’t uniquely identify the contents of updates. That means they do not work well in contexts where multiple offline clients are likely to make several updates AND submit those updates at the same time. For example, clients A and B get EntityA version 1. They both go offline and generate versions 2, 3, 4. If they then submit at the same time, the server may interleave versions from the two clients leading to a difficult history to understand. We believe that this kind of scenario is rare.
Likely approach: If a server received a submission with a baseVersion greater than the server’s current version for that Entity, the submission is held in a processing queue until earlier submissions are received.
We have since changed our thinking a little bit and are planning to have a stronger guarantee of order. We'll likely keep baseVersion as the base server version that was used and add an additional attribute to indicate what local client version the submission resulted in. There are a few notes at the bottom of the doc around that. We will finish that spec design once Collect has an offline entity representation and solicit feedback on it as well.