Less is more; worse is better. I don't remember where I originally saw it, but some rules of thumb that seem to serve well are:

- information shown to the user should be able to be consumed; if it's too fast to read and not displayed in perpetuity (e.g. logged once complete) it's essentially just unnecessary movement akin to a really noisy "spinner"

- no new "movement" (e.g. spinnner/progress esque) within ~200ms will result in the user thinking something is hung

- every permanent line away from input command prompt is sacred; e.g. too much movement vertically (e.g. spamming logs) should be reserved for "verbose" output where the user explicitly asks for it. The effort by the user to scroll the buffer afterwards should be worth it.

The new zig progress IMO breaks a these rules and I'm not a huge fan of it except out of novelty in design.

Cargo's current output essentially only breaks the vertical scrolling rule; if I were BDFL I'd probably just use a single line indicatif spinner ephemerally instead of displaying all "downloading" and "compiling" lines unless someone asked for a "verbose" output and wanted to actually see those lines logged. It could be argued that using a tree of indicatif spinners for long running parallel tasks might be interesting? But determining what is "long running" would be extremely difficult to know ahead of time, and accidentally making an 8-frame spinner would just appear like useless noise. Add to that the max parallelization with Rust, especially in debug builds can be quite high which would end up looking much like the this zig output where 99% of the lines only last for a few frames.

The vertical scrolling has the advantage that when you are watching a build go, and you see a certain step's taking a long time, it doesn't ever disappear from the terminal completely. You don't need to look through dependencies some other way and figure out which matches the thing you saw, or do a clean build to see the bottleneck again, etc.