MobiLink knows the remote schema since that is uploaded by the remotes. This happens during the first time that schema is synchronized with the MobiLink process instance. As already noted, this is how the MobiLink scripts are able to use column names, using the "{ml r." and "{ml o." MobiLink "row parameters" expansion for column values.
On subsequent syncs (relative to the same MobiLink instance) the remote may or may not upload its schema. It will do so if the signature of the remote schema does not match any of those MobiLink has in it's cache of remote schemas. It does this because many remote designs have huge schemas and to transmit those on every sync can be very innefficient (especially in situations where it exceed the size of the data needing to be synched).
It may be possible, that in some rare cases two very similar schemas might collide on the same signature. If that occurs the values may come up the order of the (unknown) schema but mapped positionally to known schema and thus the values may arrive at the consolidated out of position as described above. I suspect this is what is happening here.
As rare as this scenario should be, I would expect the mis-mapping to often cause some other errors to expose the reaons (column type mismatches being a likely possibility) and not silently but incorrectly succeed. But from the description so far, that may happen since all the value are type compatible the operation incorrectly succeeds; if out of order.
Running with a different script version for the different remote schema is expected to help resolve this. That may or may not be able to utilize the {ml row-parameterization ... I have not checked into that aspect of this yet myself ... but, if not, positional parameterization should be able to be used to address this if only to dig your way out of this lost data scenario until you can fix the schema divergence.
Hopefully that approach won't be too painful.