Wrong order of accidentals in altered unison
1) An accidental on another note in a chord with an altered unison switches the order of the accidentals on the altered unison. > 
Related:
2) MuseScore does not set the recommended order of sharp-natural by default.
Link to forum thread with a good explanation of why this is a bug:
https://musescore.org/en/node/307193
The problematic .mscz file:
Concerto_in_F,_III.Allegro_agitato (2).mscz
File created in MuseScore2, elements will get mixed in MS3. Bug still present in newest version of MS3. Picture is from measure 31.
Workaround (as stated in the forum thread):
"A rather non-intuitive workaround might be to enter the accidentals in the wrong order in chord with the B natural - i.e. natural-flat. Then adding the natural should switch them back to the correct order."
Thank you for the fix! :)
Comments
As I recall from when I tried working on this years ago, an issue is that it's a bit non-deterministic as to which note actually gets added first, because we sort a combination of line and pitch at a time when one or the other might not be known yet. I'm sure there is a solution, though.
From my experimentation adding an altered unison, the order of the accidentals is the order in which the notes are entered. eg if you enter an F# and then add a Fnat (with ctrl down to get to the correct octave) you end up with the order sharp-natural. If you enter Fnat and then add a F# you get natural-sharp, which is wrong according to Gould who says it should always be sharp-natural to avoid being confused with cancelling a double sharp.
Hmm, it doesn't actually work that way for me, F Up Shift+F Ctrl+Down still displays natural first. I don't know a reliable way to get it the other way around, except by adding another accidental elsewhere in the chord. This of course shouldn't really change anything, but it does, hence the current bug report. But, it's kind of a convenient bug, because it fixes what would otherwise be the wrong order, no? That is, by default you always get natural first as far as I can tell, but as soon as you add a third note, you get natural second.
Looking at the code, it does seem we do our best to sort things correctly upon adding, so I think the issue really is more in the layout of the accidentals. The algorithm doesn't special-case unions so the order depends on how the zig-zag work out (that's the basis of the algorithm - layout top, then bottom, then start zig-zig-ing). So probably there is a fix in there somehow.
In reply to Hmm, it doesn't actually… by Marc Sabatella
Perhaps it is the method of adding accidentals that gives different results. I have set up shortcuts for note input sharp (#), natural (=), and flat (-). So my input would go #F =Shift/F ctrl/down Shift/C to get a chord of F# Fnat C and this would have sharp-natural in front of the Fs. If I go -F #shift/F ctrl/down Shift/C I get the same chord but with natural-sharp in front of the Fs. If instead of Shift/C I use -Shift/B I get a Bb in the chord and the order of accidentals in front of the Fs is reversed. The same reversal of the accidentals in front of the Fs occurs if I add any third note with an accidental to the chord.
See https://github.com/musescore/MuseScore/issues/8993
The score from the initial post stems from 2.3.2, the measure from the image in the initial post looks identical in 2.3.2 and 3.6.. The image is not from measure 31, but measure 11...
Allegedly fixed in master and so in MuseScore 4
Automatically closed -- issue fixed for 2 weeks with no activity.