The approach presented here does not provide any standard to programmatically extract the information that is to be displayed in the messages. It seems, though, there is no need for this.
As a structured logging & tracing advocate this could not be more untrue in my experience — structured logging requires this contextual data to be accessible. Error messages must not be high-cardinality with dynamic information, such as "copy: foo.json to bar.json", as it is difficult to index and query against.
Ideally we have access to all contextual information as fields, and the primary "message" is either a single or sequence of low cardinality strings. The current printing interface does not accomplish this at all, I think it's awkward to have the error format itself, if we standardize some kind of error "fields", then a top-level function can perform the formatting, or in the case of structured logging, can simply produce a transmission or storage format such as Parquet or JSON.
Not sure if that's what you want, but you can already create a good-enough json error message.
See https://play.golang.org/p/eNLfIZpqc4B.