The article in question from the last "This week in Rust".
Very thought-provoking read. In my experience on Arwen, I enjoy the use of 'thiserror' in our client crates as vehicles for documenting and listing all the errors we care about, saying nothing of how we should handle them. We interpret the HTTP codes, the error messages, and then document how we caused them in the Display impl. I then lean heavily on logging as the debugging method of choice within business logic, and eschew making the error type itself contain all that information. I also do as the article says and never use .context() with anyhow errors, mainly because I don't have a strong heuristic for using it, as good as I know it is. Consequently, I don't know what I'll get when printing or logging it (usually not much), so I always print both the Display and Debug version. This disconnect is a bit annoying since it means I tend to duplicate context or lose it entirely.
The form of the error struct suggested in the article could be used across the whole platform, revealing an explicit structure and a predictable output. It would also serve us well in building our API for the front end too, since a missing part of our error story is a standard way to define the error messages we return there. With this form, we can just always use the message field (for example) and be careful about what to put in there.
P.S.
An addendum to the library/application argument which I've not yet seen mentioned, is that, as a developer, YOU are the end user for what you are building, until it's built and becomes used automatically by the machine, which means that a given module can be on both sides of the lib/app divide during its development. How many times have you added info logs only to downgrade them once you know the thing does as you expect? How can you determine which errors are transient without having them printed somehow (anyhow?) at first?
It's the same argument for how to structure the Display versus Debug implementation on Errors. Debug is for when you, the developer, want to make sure that the error type you are crafting has the right form. Display is for when the error type is working as expected and faithfully and usefully explains itself. I should never be printing the debug of an error in production, just as I shouldn't have debug logs on by default.