Squash commits confusing and broken in interactive rebase

The interactive rebase function in SourceTree is very confusing.

For starters, when using "squash with previous", the commit message that "wins" is the newest one. Typically, I have an older commit called "Implement feature X", and then a newer commit called "Fixup feature X". When I squash these two, I almost always want the oldest commit message, and not the newest as I get today. I can't even imagine a use case where the current behaviour is desired.

Secondly, and the reason for this bug report is that when squashing multiple commits they very easily end up out of order, leading to a merge conflict and failed rebase. Consider this commit history.

• Fifth commit
• Fourth commit
• Third commit
• Second commit
• First commit

Doing interactive rebase on "first commit" here, and then selecting "third commit" and "squash with previous" gives this:

• Fifth commit
• Fourth commit
• Third commit (+1 squashed commits)
  • Third commit
  • Second commit

Now, selecting "fourth commit" and "squash with previous" gives this:

• Fifth commit
• Third commit (+2 squashed commits)
  • Third commit
  • Second commit
  • Fourth commit

And the same with "fifth commit":

• Third commit (+3 squashed commits)
  • Third commit
  • Second commit
  • Fourth commit
  • Fifth commit

This leads to SourceTree starting with applying "fifth commit" to "first commit", which quite likely will fail with a merge conflict.

However, squashing the commits in the opposite order does seem to work as expected (First "fifth commit", then "fifth commit (+1 squashed commits)", then "fifth commit (+2 squashed commits)"). However, given the workflow I use, this is not at all intuitive. I would squash the first (oldest) fixup into the main commit, then the second fixup, etc.

It seeems like this ties into the reversed sort order that SourceTree uses in interactive rebase (git rebase -i sorts the commit with the oldest first, while SourceTree interactive rebase sorts the newest commit first). I understand that it's intuitive to use the same order in the rebase window as in the main commit history, but squashing gets very unintuitive with this order. I would argue that sorting the commits in the order they will be applied (like git rebase -i does) is more intuitive both to people who are experienced with git rebase -i and to people who only use SourceTree (provided that the order of commits is explained in the rebase dialog).

Finally, I just noticed that if you press "cancel" in the rebase dialog, you get an error message: 

git -c diff.mnemonicprefix=false -c core.quotepath=false -c "sequence.editor='C:\Program Files (x86)\Atlassian\SourceTree\tools\stree_gri'" -c "core.editor='C:\Program Files (x86)\Atlassian\SourceTree\tools\stree_gri'" rebase -i --autosquash 953b98728a420d0ff3f4ded5284eb8718d1fe2fa
Could not execute editor

Completed with errors, see above.