I'm well aware of Go patterns. That is not the point. The point is that the language allows you to return as many values as you want, in any order, of any type. If you introduce a new operator, then that operator should not be driven by a community pattern, but a strict language specification that covers all the use cases allowed by a language. It should also explain how an operator behaves in weird scenarios (eg return err, Type{} vs return Type{}, err). It can surely be all explained by the spec, but Go is the language that wants to minimize "weird scenarios". The best operator is the one that doesn't need explanation.
> the ? operator could simply not be applied in this case.
No. Go doesn't want to have such operators exist at all, because they are not simple. Go wants to find the most common denominator that would elegantly solve an issue from all angles in such a way so that the authors don't have to write pages of specification, but most importantly, so that code readers don't have to read specification when glancing through code.
Having a ? operator that avoids the `if err { return nil, err }` would be awesome.
The case you are representing is a clear "anti-pattern" in Go IMHO. Why should a function return two errors?
In any case, the ? operator could simply not be applied in this case.