UMLR — Timing Diagram and interchange

In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another.
In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle".

Some facts:
If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram.
StateInvariant is an InteractionFragment.
The StateInvariant is kept in the Interaction::Fragment ordered collection.

Issue:
The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state?
StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first.
Having to duplicate the StateInvariant and/or Constraint seems incorrect?
( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous )

Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient.

Any insight would be appreciated.