I know all the options I have and I have read everything Dave Cheney (and Rob Pike) has written on the subject. But to quote myself: "there is no way to add instance specific information to errors in a later version of a package".
Once you have decided to use a package level error value (sentinel error as you say), there is no way to change that.
As there is a huge number of such error values in the standard library and also a substantial number of other types of errors like PathError, "there is no general and reliable way to handle specific types of errors".
Methods can always be added. Yes the values and types can't be changed but we can extend the existing types to have these methods and give naked error values (errors.New) new types. It wouldn't be breaking the Go1 guarantee because they would still have the type error, only the underlying type would change.
All true, I never said anything different. But what's the point of adding methods?
What you can't do is add call specific information to errors returned from a particular function if that function returned a package level singleton value before.
I see. This isn't always true, many places in the standard library do not document what error they will return. Changing these wouldn't violate the Go1 guarantee either.
I see that other people have made the argument in support of Dave Cheney's approach already so I won't repeat it.
If I'm understanding you correctly, your complaint is that the errors are part of your packages API, so there is no way to change the errors you return without making breaking changes to your API contract?
Once you have decided to use a package level error value (sentinel error as you say), there is no way to change that.
As there is a huge number of such error values in the standard library and also a substantial number of other types of errors like PathError, "there is no general and reliable way to handle specific types of errors".