Note that the message ends 1s and 1r denote the ends of AsyncMessage1. If we now perform a semantic move to either above AsyncMessage2 or the CreateMessage1, the end 1r is not moved accordingly.
Update:
Playing arround with this, I observed that once it is moved above, it doesn't allow "graphical" move anymore (without Ctrl), which seems to be because the getTop() and getBottom() of the receive event returns the old values (before the first move). When moving again with Ctrl without crossing another fragment above or below, it gets updated correctly and the semantic order is correct again.
Consider the model in reorder-with-create-message.zip, where we have the following interaction:
Note that the message ends
1sand1rdenote the ends ofAsyncMessage1. If we now perform a semantic move to either aboveAsyncMessage2or theCreateMessage1, the end1ris not moved accordingly.Update: Playing arround with this, I observed that once it is moved above, it doesn't allow "graphical" move anymore (without
Ctrl), which seems to be because the getTop() and getBottom() of the receive event returns the old values (before the first move). When moving again withCtrlwithout crossing another fragment above or below, it gets updated correctly and the semantic order is correct again.