One of the things I picked up from Dave Winer around 20 years ago is that errors messages should be of the form "Can't X because Y", and while I don't quite always use that exact grammar form, my errors pretty much all take that form when there isn't some other overriding local standard for errors. It's not a bad template. Most error messages will give you some hint about the Y, but the difference between "Error: file system full" and "Error: couldn't open log file '/var/log/myapp.log' because: file system full" is pretty substantial, especially if system state has mutated in the meantime and by the time you get to the system, none of the filesystems are full anymore.
Descriptive errors that match the business logic are ideal in many cases. Clearly, one shouldn't don't divulge "secret" validators.
More on the topic, I'm really happy to see this coming in so far ahead of 2.0. I want to get ready for 2.0 because of the gains I hope to see in idiomatic go in 2.0.
This is the general strategy when developing "2.0": do as much as possible in a backwards compatible way, and if we never need to make a breaking change, never call a release 2.0. The new features process that was introduced recently may result in a 2.0 release, or it may result in 1.999, so you will continue to see new features in each release for a while regardless of what the release is called.
The biggest issue I have with most error messages is that they say things like you have here but don't reflect back the data that caused the error, i.e. show me the phone number you think I sent you.
I think this context is really hard to carry around, and if you aren’t extra super careful you can end up leaking passwords and other secret bits of memory here to logs. Better to just give me a place to put a debugger breakpoint IMO.
Fill in the blank "Well basically what happened is ___________"
For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"