The developers are going to have broader options on how to print the returned error. That is one benefit of this improvement.
In addition to that, go-sarah itself also prints some errors with a logger -- the go-sarah's default logger or a logger implementation given by a developer. Checking how the format works on the error implementation of old errors package and new xerrors package, and choose the one that has the smallest impact is vital. The ideal formatting is that current logging parts work as-is when old errors is returned from a depending third-party library and switch to print richer information when the depending library migrates to xerrors.

As of Go 1.12, when v, s, x, X or q is given as a verb part, passed argument's error.Error() or Stringer.String() is called as long as the argument implements error or Stringer.
https://github.com/golang/go/blob/3a1b4e75f8b6c1b57db73bccf7ca871bf1a97ca9/src/fmt/print.go#L600-L619

Format behavior of current error implementation

Because xerrors prints stacked error with its own fmt.Formatter implementation when %+v format is given, below test with current error implementation focuses on formats with v.

package main

import (
	"fmt"
)

func main() {
	fmt.Printf("%%s:\n%s\n\n", &myError{"this is my error string"})
	fmt.Printf("%%v:\n%v\n\n", &myError{"this is my error string"})
	fmt.Printf("%%+v:\n%+v\n\n", &myError{"this is my error string"})
	fmt.Printf("%%#v:\n%#v\n\n", &myError{"this is my error string"}) // v with sharp is treated differently
}

type myError struct {
	field string
}

var _ error = (*myError)(nil)

func (e *myError) Error() string {
	return e.field
}

The output is as below:

%s:
this is my error string

%v:
this is my error string

%+v:
this is my error string

%#v:
&main.myError{field:"this is my error string"}

Format behavior of xerror implementation

package main

import (
	"fmt"
	"golang.org/x/xerrors"
)

func main() {
	err := outer()
	fmt.Printf("%%s:\n%s\n\n", err)
	fmt.Printf("%%s with error.Error():\n%s\n\n", err.Error())
	fmt.Printf("%%v:\n%v\n\n", err)
	fmt.Printf("%%+v:\n%+v\n\n", err)
	fmt.Printf("%%#v:\n%#v\n\n", err)
}

func outer() error {
	err := middle()
	if err != nil {
		return xerrors.Errorf("failed calling the middle method: %w", err)
	}
	return nil
}

func middle() error {
	err := root()
	if err != nil {
		return xerrors.Errorf("failed on root method: %w", err)
	}
	return nil
}

func root() error {
	return xerrors.New("buzz")
}

The output is as below:

%s:
failed calling the middle method: failed on root method: buzz

%s with error.Error():
failed calling the middle method: failed on root method: buzz

%v:
failed calling the middle method: failed on root method: buzz

%+v:
failed calling the middle method:
    main.outer
        /Users/Oklahomer/dev/xerrors-sample/main.go:19
  - failed on root method:
    main.middle
        /Users/Oklahomer/dev/xerrors-sample/main.go:27
  - buzz:
    main.root
        /Users/Oklahomer/dev/xerrors-sample/main.go:33

%#v:
failed calling the middle method: failed on root method: buzz

Conclusion

Current logging parts mostly use %s with "error.Error()." This keeps working in the exact same manner as shown in the above test results when xerrors is used. However, that cannot benefit from the new xerrors feature to print stacked errors in a hierarchical manner.
The test results suggest that below formatting maintains working in the same way with old error and still benefits from xerrors.

fmt.Printf("error on blah blah: %+v", err)
log.Errorf("error on blah blah: %+v", err)

from go-sarah.