I've used Rust full time for approximately three months. I'd like to share with you my greatest peeve. It's relatively minor yet important enough to warrant this post: The compiler error count is misleading and harmful.
The Rust compiler presents an error count that will change with each change since last compilation. Because of this, resolving one error from an error count of 3 can turn the total error count to 19, without introducing any new issues in implementation.
While reading this, you may find yourself leading to a reasonable technical explanation that there are limitations with compiling that won't allow for improved counting. Stop. The problem isn't technical. The problem relates to communication and design (user experience).
How is this harmful? The error count sets an expectation-- a goal. As the goal post moves from 3 to 19, one may experience a sense of anxiety. A moving goal post is demoralizing.
So.. What can be done to improve the experience of working through errors?
My thoughts: The compiler follows a sequence of checks. Can each step of the sequence be named, operations categorized? If so, the compiler can communicate what steps were checked, which are pending, etc.
I remember being taught the myth many years ago of compile once gives all the errors. I think it is mostly down to your perception that the number is a goal.
I sort of like your idea of categorised progression but don't see it adding anything meaningful and may be a barrier to categories changing. With experience you get a sense for which errors (missing/miss-matched parenthesis) comes first.
The most common step is down to the developer; to write less code between compiles/tests. Rust has gone further since developers don't like the time compiles/test take so it supplies check. With an IDE this is automated through RLS.
While I kind of understand the moving goal posts being demoralizing, this is also a matter of the user's expectations/previous coding experiences.
In other languages compiler errors are not as common because they let you get away with more things. For that matter they only flag the most fundamental issues with your code, i.e. syntax errors and the like.
In Rust you have more safety guarantees and while it can be frustrating to deal with these errors at compile time, you can also be more confident your code is actually correct when it compiles (barring logical flaws that can't possibly be checked).
I do actually see the issue that OP is raising and I could also agree on the moving target issue.
Moreover I do also believe that small recompilation are not always possible and I found myself in the position of doing big refactoring without the possibility to compile in between. (Maybe I could have managed it better but still.)
I don't see the necessity of such improvement, it could be weird at first, but after few times you figure out that there are different phases of compilation and each could result in one more more error and that the compiler stops at the first phase that raise errors.
However I would still find useful to signal what phase of the compilation actually went well.
Like at the bottom it could appear something like 'syntax check Ok' 'type check errors'