In my experience, errors returned by the standard library and recent third party packages are fairly well discernible, although not in all cases.

Note that you don't need custom error types, just exported Error instances. These were in use even before wrapping was introduced with Go 1.13 (2019); one had to compare or type-assert directly instead of unwrapping.

You can use %w in fmt.Errorf to accomplish this.

Not really. If the original error is `fmt.Errorf("divide by 0")`, no amount of `fmt.Errorf("failed to divide: %w")` will help anyone programmatically recognize the error.

Yup, fair point, I thought we were talking about libraries replacing errors to obscure the original, which absolutely happens. Lots of libraries (e.g aws-sdk) do use typed errors, so wrapping them correctly for smaller libraries that compose them is important.