> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder.
I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.
Depending on what is in your cache, Maven will satisfy dependencies differently. You can go out of your way to nail down your dependencies (analogous to a Javascript lock file) but it goes against the grain of how Maven is designed. Maven encourages pretty sloppy dependency resolution by default, and that's what you'll see if you look inside the artifacts you depend on.
There may be other issues as well, because this was an issue that affected Maven throughout my years of using it, in contrast to SBT, which in my experience had this issue much less often (though it definitely did from time to time.)
Can probably happen like it can happen with any dependency management system - if you set wildcard versions (or no version at all?), different systems can have different versions of the dependency cached. Eventually this can lead to surprise build failures.
I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.