This is very hand-wavy, but I think we're talking at a very high level of abstraction here. My main point is to suggest that there is more of a balancing act here than perhaps your words suggest.

But that's exactly what you do when you...

>... try to indicate the different types of errors that could occur and what type of information needs to be included to be useful to the caller.

Modelling the error domain means to decide which possible distinctions matter and which don't. This is not self evident. It's you imagining what users may want to do with your errors.

Is it enough for the caller to know that some string you're parsing is invalid or do they need to know what it is exactly that makes it invalid?

If you decide to just pass on everything you happen to know based on your current implementation then you are putting restrictions on future changes to that implementation, potentially including the use of third party libraries.

What if you find a shortcut or a library that makes your parser 10 times faster but doesn't provide this detailed information?

What I see a lot in Rust is that massive amounts of implementation details are leaked via errors. thiserror actually encourages this sort of implementation leak:

  #[derive(Error, Debug)]
  pub enum MyError {
      Io(#[from] io::Error),
      Glob(#[from] globset::Error),
  }

Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. It is reasonable to assume that you would want to handle them differently. If your function can actually have both errors as a consumer I would want to know that so I can make the correct decisions in context. If you don't have a way to signal to my code that both happen you've deprived me of the tools to do my own proper error modeling and handling.

You are implying that there is one correct and self evident set of distinctions. I disagree with that. In library design, you're always making assumptions about what users may want. In my opinion, this is even harder when modelling errors, because there are so many possible ways in which callers might want to respond.

>Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors.

Of course. I'm not complaining about the distinction between io errors and globbing errors here but about the fact that the globset library and its specific error type is leaked.

What if someone (say fastburningsushi) comes along and creates a glob library that absolutely smokes this one? :P