This code:
    
        foo, err := someExpr
        if err != nil {
            return nil, err
        }

    Is entirely boilerplate

But you'd never write that, you'd write

    if err != nil {
        return nil, fmt.Errorf("some expr: %w", err)
    }

which is _not_ boilerplate, in any sense that would benefit from being mitigated with new syntax or short-cuts.

> Condensing that particular snippet down to `?` would be less terrible than the status quo

This simply isn't any kind of objective or agreed-upon truth. Many people, including myself, believe that the status quo is better than what you're suggesting here.

People who are annoyed with Go at some fundamental level, and who largely don't use the language themselves, delight in characterizing `if` blocks related to errors as "boilerplate" that serves no purpose, and needs to be addressed at a language level.

> `?` is exactly in line with `iota`, `foo_windows.go`, `flag.Var`, `http.HandleFunc`, etc.

I've thought on this at length and I have no clue as to what you think the common property between these things might be. A proposed language sigil that impacts control-flow, an existing keyword that's generally not recommended for use, a build-time filename convention, and two unrelated stdlib type definitions?