The expected way that stack would work:
you select multiple items and choose ‘stack’
=> the vertical order of items is maintained and they are aligned and nicely spaced
BUG: the vertical order is messed up, sometimes reordering happens for no apparent reason
(I have not found out what the wrong logic is exactly, it seems to depend on which items were touched last. I can totally see how they are in a list internally and you just use that list’s ordering)
Bugs like this are almost impossible for us to act on by their mere description, without more concrete data to work with. An example board, for instance, attached to a response here, that demonstrates an A, B, C type setup that goes C, A, B (or whatever it takes), along with any precise instructions on which items to “touch” in what order, would be ideal.
It would be AN EASY task to just play around with “Stack” and see.
But you are lucky that my slightly above average intelligence has figured it out:
“Stack” takes the order in which items were selected and turns that into vertical ordering.
Which is still unexpected, especially if one drags a selection box over the items FROM THE BOTTOM.
I maybe wrong but the stacking is based on distance (not based on vertical but separation distance between notes and the first note choosen for the stack.) from the first object choosen. The other notes stack based on distance from the first note. If you play and change the distance from the first note, you will see the stack order change. I tested using notes numbered one to five. (windows version.)
It not a BUG, it’s a FEATURE! (lol)
The nature of how it works is described in the user manual, and yes it’s basically what @GoalieDad put:
Select the notes you wish to arrange into a stack. The first note you select
will not move, and subsequent notes will be placed under the first note in
order of distance from the first selected note.
Searching the forum for stack ordering probably also would have lead you to places like this post, where that was discussed. You might then have also noticed how that conversation involved finding a case where the software wasn’t really following the intended rules (a bug), and how it required very specific sample data to trigger it.
Hence…