In addition to the tradeoffs the article discusses, one other potential use for using traits rather than concrete error types is that you could also choose to u

In addition to the tradeoffs the article discusses, one other potential use for using traits rather than concrete error types is that you could also choose to use a different container than `Box` if you need different properties. As an example, one library I worked on needed to track errors that might occur in background threads and sometimes return them (or merge the info in them with other errors) to users when an operation failed later. Because the client the library provided could itself be used concurrently, this meant that we sometimes had to return the same error (or at least, parts of the same information from the error) in multiple different threads, and not all of the error types we wrapped were possible to Clone. Wrapping these errors internally in an `Arc` made it possible for us to clone our top-level error type and greatly simplify our internal logic handling these cases. I imagine that this isn't a particularly common problem people well run into, but at the very least being able to wrap `dyn Error + Send + Sync` is a nice example of how composable a lot of the concepts in how to design an API in Rust are.