Dynamics should not move their anchor points when being dragged with the mouse

Agreed. The good news is, for dynamics, keyboard adjustments works fine. That wasn't true for lines and thus was more crucial to get a fix in place there.

a) If you hold down CTRL+SHIFT after you start dragging it will prevent re-anchoring
b) the biggest issue I can see is that re-anchoring is too eager when you drag across a barline. Normally it seems fine, it only re-anchors once the element is dragged to the left-edge of a new note/rest, but the moment the centre of the element slightly cross a barline it reanchors which is an issue as it's not that uncommon to need a dynamic to start before the barline but apply to the notes after it (esp. if it has additional text).

To me the worse problem is re-anchoring to a different staff entirely, which is all too common and of course wreaks havoc with playback.

For me that only occurs when the dynamic is explicitly dragged right on top of another staff, which is arguably unexpected as that's not somewhere you'd ever want the dynamic to be - but once it's reparented you can then drag it where you actually want it. But if you really do want your dynamic to sit on one staff and belong to another, Ctrl+Shift will let you do so.

No doubt it depends on the nature of the score - how crowded the notes are both horizontally and vertically, where the dynamic is positioned relative to them, and also the scaling/zoom factor which has to do with how easy it is to be precise in mouse movements. I also think this may have been improved in the last year or so, I recall we tweaked the algorithm specifically to favor the current staff more. Anyhow, it's still not very well controlled in my opinion, not a good idea to begin with, and the large numbers of complaints over the years bears this out.

I feel that for lines, it's probably more common to want to change the actual anchor than to merely adjust physical end points. But for dynamics, it's very much the other way around. It rare to enter a dynamic on the wrong note then want to drag to fix it. it's super common though to want to manually position dynamics - specifically in the sort of crowded conditions where problems are most likely to occur. So it's not even a given to me that the same approach makes sense for both.

It's not just a question of putting it on the wrong note - we composers/arrangers often change our minds after writing one thing, and may, for instance, choose to add another note or two the start or end of a phrase where there was already a correct dynamic (or other direction such as "pizz." etc.), but it just now needs re-anchoring to one of newly added notes.

BTW I have noticed since that while single dynamics such as p and f are fine, multi-letter dynamics such as mp (and certainly something like subito p) etc. do tend to re-anchor to the following or previous note a bit too eagerly, which would be worth fixing - e.g. I believe the hit test is based on the horizontal centre point of the dynamic rather than the left edge (for re-parenting to a later note) or right edge (for re-parenting to an earlier note).

Sure, it's not just wrong notes. But still, as a composer myself., I would estimate I move dynamics for visual reasons probably around 10 times as often as I ever change the note they are attached to. I can't see how my experience would be unusual, but I suppose gathering data could be useful. Anyhow, the point again is that both actions are useful, so it would be good to have a really well-designed interface to allow both of them in a natural way, one that feels equally good for text as for line even if the specifics might work differently,