I believe it’s unspecified whether 0 or 1 is stored in m[0], but it’s not undefined behavior.
The LHS and the RHS can occur in either order, but they’re both function calls, so they both have a sequence point at the start and end. There’s no danger of the two of them, collectively, accessing the same object without an intervening sequence point.
The assignment is actual int assignment, not a function call with associated sequence points, since operator[] returns T&. That’s briefly worrying, but it’s not modifying an object that is accessed anywhere else in this statement, so that’s safe too. It’s accessed within operator[], of course, where it is initialized, but that occurs before the sequence point on return from operator[], so that’s OK. If it wasn’t, m[0] = 0; would be undefined too!
However, the order of evaluation of the operands of operator= is not specified by the standard, so the actual result of the call to size() might be 0 or 1 depending which order occurs.
The following would be undefined behavior, though. It doesn’t make function calls and so there’s nothing to prevent size being accessed (on the RHS) and modified (on the LHS) without an intervening sequence point:
int values[1];
int size = 0;
(++size, values[0] = 0) = size;
/* fake m[0] */ /* fake m.size() */