Incorrect alignment of tones/semitones

[Dima-S-Jr]

When notating two voices on the same staff, special attention should be paid to the horizontal alignment of adjacent chords (with two stems). It is important to understand which voice each note belongs to. The example below shows the auto-placement (currently existing in Musescore) of adjacent chords (consisting of two voices) having tones/semitones. Try to determine which voice each note belongs to. Agree that it is not easy to do this. This shouldn't happen. Don't tell me I have to look at the small gap between the stems. Instead, the lower part (the second voice) should be shifted slightly to the right to clearly separate the two voices.

Steps to reproduce

1. Enter the chord of the 1st voice in tones/semitones
2. Under the entered chord of the 1st voice, enter the chord of the 2nd voice with the same intervals (tones/semitones)

MuseScore Version

MuseScore version (64-bit): 4.2.1-240230937, revision: github-musescore-musescore-d757433

Additional context

This applies not only to half notes (minims), but also to all other note-values. The most incomprehensible situation is with whole notes (semibreves) - it is generally impossible to determine which voice each note belongs to

Prior Art

Unlike Musescore, Sibelius has a horizontal offset between the chords of two voices:

[Dima-S-Jr]

@oktophonie, of course, I understand that it is not for me to determine which labels issues should have, but wouldn't it be wise to remove the "feature request" label from this issue, since the problem I have outlined is really relevant, and in some scores it is extremely important to understand which voice the chord belongs to with tones/semitones (especially for whole notes). If you are sincerely convinced that this is not considered a mistake and it is not worth it, then this is, of course, your right. It is not for me to determine which labels to put on this request (however, I ask you to pay close attention to this issue).

[cbjeukendrup]

The "feature request" label is applicable from a technical POV: this issue is not caused by a piece of code that is working incorrectly, but by a piece of code that simply doesn't exist yet.

[Dima-S-Jr]

The "feature request" label is applicable from a technical POV: this issue is not caused by a piece of code that is working incorrectly, but by a piece of code that simply doesn't exist yet.

Thanks for the clarification. Indeed, this is logical. Most likely, I do not quite understand the purpose for which certain labels are put on issues. But as far as I know, there is also such a label as "priority" with different degrees of importance. I probably meant it.