Currently, dragging or keyboard nudging the end handles of a line
will always try to find a new anchor point to attach to.
This makes it virtually impossible to obtain certain layouts
where you deliberately want a line to extend before or after a note
but still be attached to that note rather than the previous/next.
Thre solution here is to simply disable the rebase of anchords
when using the keybaord to perform the adjustment.
In addition, for mouse users, I allow the Ctrl modifier
(which also constrains drag to horizontal)
to perform this same function.
Dragging a dynamic out of an empty measure into an adjacent mmrest
causes the original measure to now be subsumed into the mmrest,
and the original mmrest no longer exists.
This leads to a crash upon trying to draw the anchor lines.
While it might be possible to re-parent the dynamic again
after the multimeasure rests are recalculated,
or to force the parent to be a segment within the underlying measure
(and then taking pains to draw the anchor lines relative to the mmrest,
since the underlying measure may not yet have been laid out),
these solutions seem likely to be complex and fragile,
depending on the specifics of the order in which layout happens.
The simpler / safer solution is to disable dragging a dynamic
into a multimeasure rest at all.
Upon dragging a line that has been aligned with other lines,
the offset is changed and is rebased to (unaligned) position
to allow it to be laid out right where you dropped it.
However, the alignment code then kicks in and tries
to adjust its position further, not accounting for the offset.
The result is the offset applied is now applied to the aligned position,
not the original position.
It is difficult to say what the "right" thing to do is here.
Clearly we want the line to end up where you dragged it,
but how it should it then respond to further changes?
It might be possible to alter the alignment algorithm
to account for this and preserve the *relative* offset
if the alignment adjustment changes in the future.
But it's not really clear how well that could work
or if it would be desired anyhow.
The simpler solution chosen here is to not try to align
any line that has a manually applied offset.
This is, FWIW, the same approach used for chord symbols.
Currently, on any drag operation in edit mode
(including "drag" via arrow keys, which uses the same code),
the offset is set to NOSTYLE, whereas it should be UNSTYLED
(if it was previously styled).
The result is that after such an edit, the offset can no longer
be reset to its original STYLED state,
so it even after a reset of the offset itself,
it remains marked as NOSTYLE and will not respond to style changes,
There is code in the ordinary drag case (Element::endDrag())
to handle this, but it is missing from the edit mode version.
The fix here is to simply reproduce that code in Element::endEditDrag().
