As briefly mentioned by OP, this behavior is not guaranteed in C. Regarding evaluation order, the C standard, roughly speaking, states that side effects will never be reordered past a “sequence point” (*). For instance, C’s comma operator , is defined as a sequence point, so a,b is guaranteed to perform any side effects of a before evaluating b. Similarly, the end of a statement (i.e. a semicolon) is a sequence point. Most standard operators, like + and =, are not sequence points in C, so the compiler is free to reorder the side effects of sub-expressions as it wishes.
Nowadays, this restriction seems rather less necessary: compilers are generally smart enough to figure out when they can reorder side effects, elide loads, etc if it would help with optimization. As such, whilst I do not know if it has been formally defined at any point, I do expect Zig to ultimately include the status quo behavior in its spec, where sequencing of side effects always happens in the order of the source code (which I can confirm is guaranteed in the current compiler implementation, and in fact would be quite difficult for us to change due to how the compiler pipeline is structured).
*: It’s technically defined differently since C11, but the new definition is basically equivalent.