> rewritten by the compiler to pass in a value or a pointer

This is only method receivers, not for arguments. Essentially the way of invoking a method on a pointer receiver (like '->' in C/C++) isn't any different than invoking it on a value receiver (like '.' in C/C++). But you can't pass 'pointer to int' to a method where 'int' is expected.

> some simple, compile-time validated sugar to pass the error value up the call chain

This bothers me a bit, too. Sometimes I was able to work around it in a creative way. Take http handlers as an example:

  func standardHandler(w http.ResponseWriter, r *http.Request) {
    // errors may occur here...
  }

You can wrap these in an error handling function like this:

  type naiveHandler(w http.ResponseWriter, r *http.Request) error

  func handleErrors(fn naiveHandler) {
    return func(w http.ResponseWriter, r *http.Request) {
      if fn(w, r) != nil {
        // handle errors
      }
    }
  }

  http.HandleFunc("/", handleErrors(handler1))
  http.HandleFunc("/", handleErrors(handler2))
  // ...

This is handy since you can handle different errors differently - eg. report, log etc - but uniformly between all handlers. To be fair the only syntactic sugar I'd need in most cases is an equivalent of a C/C++ macro:

  RETURN_ERR_UNLESS_NIL(/* Go expression returning only error */)