Strange behavior when offsetting linked dynamics

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

Current behavior: Linked dynamics sometimes extremely difficult to drag/offset. Origin of the impedance unclear.

Steps:

Align several consecutive dynamic &/or expression text
Place a slur in notes on the same voice and staff as the attached dynamic
Shift the block up to overlap with the slur.
--> collisions impede the block in puzzling ways. Have to select different elements one after the other to move the block by tiny amounts before it stops and you have to find the next moveable element.

The impedance does not appear to follow any evident logic (such as -say- "the colliding dynamic is the one that is stuck").

Expected behavior Unclear. First, I think that objects that don't normally collide with dynamics -like ordinary objects (slurs, stems..) on the same staff or in the same voice as the attached dynamic- should not collide with linked dynamics.

The desired behavior is probably unrealistic, given the auto place system and the hidden offsets. But this seems much more squirrely than before the improved-dynamics-alignment update.

Supporting files, videos and screenshots

Arbitrary illustrative task: Shift the linked dynamics upward until they touch the lower line of the upper staff. https://github.com/user-attachments/assets/72100c0f-494d-45cd-b407-221ba7c4e491 Once I select the first object, I am tapping the keyboard up arrow ↑ rapidly, throughout. Wherever the dynamics are not moving rapidly upward, the selected object will no longer move.

File used is here. linked dynamics.mscz.zip

Auto-place is on, but this is not a problem for any of the linked objects individually; they do not collide with the slur on the same staff.

What is the latest version of MuseScore Studio where this issue is present?

4.4.2-242570931, revision: 3130f97

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

Mac OS12.6.6

Additional context

I used a narrow, reproducible example. The problem is not just slurs, but I did not identify a rule. Something like "some objects now improperly collide with linked dynamic, collision behavior puzzling" which is desperately unspecific.

"Worked in previous version" is relative. There are always small issues like this when working with autoplace but something changed in 4.4. Dense sections with busy center space can explode, movements become jerky and unpredictable, or objects just lock down and won't move anymore.

Workaround seems to be to turn auto-place off on everything and make the necessary adjustments (like adding a staff spacer to keep the non-attached staff from encroaching.

Sorry I could not be more specific.

Checklist

[X] This report follows the guidelines for reporting bugs and issues
[X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
[X] I have attached all requested files and information to this report
[X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Humans, I have either failed to isolate a proper example, or the issue is not what I thought. I have been seeing dense scores explode or become virtually uneditable when I open them in 4.4. However, double-checking this example in 4.3, the behavior is different, but no less bizarre or more desireable. 4.3 plays the "you push it up then I'll push it back down" game as an infinite loop. Since the three elements regularly split apart and land at different heights, this alone may account for the release of tension and lack of explosions until 4.4 linked them properly.

The behavior of both versions still feels like it can't be the intended result, and it also still seems like an error to have collisions with elements that none of the individual components would collide with. If I run across an example that cannot be explained without some new complexification I will post it.

Sorry for a half-red herring :(

musescore / MuseScore