Absolutely. If there is no reason to distinguish between different types of errors then defining different types is a pointless distraction that clutters the AP

Absolutely. If there is no reason to distinguish between different types of errors then defining different types is a pointless distraction that clutters the API. So let's simply return errors.New("...") or a private package level error value. But public package level singletons are a completely unnecessary burden on API versioning with no upside at all. Why on earth would I ever want to make a lasting commitment to never attach any data or call specific message to errors in the future?