(I should note that most of the time in an interactive rebase I type "git commit --amend --no-edit" because I know I don't want to edit the commit message; that also means I don't see the UI that might have given me a hint that stuff was going to go wrong.)

That doesn't work if you're developing a series of changes that are supposed to make sense separately.

I can explain with links to examples when I'm back at my computer

So both the layout and DOM teams at Mozilla have a strong culture of producing small patches where each step compiles. This makes code review of large changes much easier, and also is useful for bisection when debugging regressions. (Other teams too, but probably less strongly.)

A relatively simple example is hg.mozilla.org/integration/a… . This was easier to code review as four separate patches than one. (#4 depends on #3 and #1. #3 depends on #2.) With more complex changes, the value goes up.

So I might write a series of six patches (probably compiling each one) before doing any testing. Then I hit a test failure and realize it's a bug in patch #2. This is before posting anything for code review. So I want the fix merged into patch #2. rebase -i.

Note that patch #1 in that series is large-ish, but it's really simple to review because it's all trivial changes, all doing the same thing. If it were mixed into a bunch of other things it would be a lot harder to review than when separated out.