Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
A tree is insufficient for flows at $dayjob, you need a directed acyclic graph to handle fanout/parallelism.
For which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.
If you can reliably break down your complex flow into a tree of checkboxes, you could just as easily render a truthful progress bar based upon how many sub tasks are done.
Context. You see not just the thing currently executing, but also the things remaining to be executed - which allows you to mentally gauge which of them may slow down.
Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.
This is the most infuriating part of progress bars to me. When it hangs I don’t even have a jumping off point for Google. I can only search “foo hangs during install” which almost always results in issues that are not the problem I’m experiencing because usually the most common reason isn’t the reason the majority of the time. “Foo hangs during ‘reticulating splines’” usually has far more useful results.
Had problem when GUI closed after trying to install a package. No error, no logs. (or was it defaulting to the normal state with install button and no logs, I don't remember)
Found out about package conflict only after running apt from the terminal.