Because, subexpression evaluation order is indeterminate in C. We really need -fprecedence-left-to-right and -fprecedence-right-to-left to specify evaluation strategies.
It is an exception to the apparent pattern in which behaviors that trap on one of the early C targets were later declared undefined.
Given the standard, it's obvious why i=i++ is undefined: it modifies i twice between sequence points. The question is why it was "undefined" (in which the implementation is allowed to make demons fly out your nose) and not something like, say, the "unpredictable" that occurs in many architecture specs (in which the program behaves as if i had been set to something in particular, but with no requirement on which value it is: unchanged is ok, incremented is ok, 12345 is ok if i is wide enough to hold it, but silently failing to generate any code for statements that occur after the i=i++ isn't).
Subexpression evaluation order has nothing to do with traps and everything to do with optimisation. It is not like your CPU requires mandatory exclusive lock to access a particular memory location.
