not an issue.
It looks like the only different between those errors (like return newUnavailable(st)) is the name of the structure, and the rest is the same.
Any specific reason we choose this approach instead of "newErrorWithCode" or something like that, that looks like

ErrorWithCode struct {
		Message string
                 Code  codes.Code
		st      *status.Status
	}

and then other "concrete" errors inherits from it? This way we may avoid reflection, and reduce number of error types.

and then other "concrete" errors inherits from it? This way we may avoid reflection, and reduce number of error types.

Go doesn't have inheritance, and if embedding this like type Aborted struct { ErrorWithCode } you aren't reducing the number of error types, and not sure what is meant by reflection here. The duplication here is fairly normal in these cases.

I am (only slightly) concerned this may be technically incompatible behavior changing an error type that users may be using. Can we make sure that this is clearly called out in the release notes of the next release of this repo?

Right; I also thought about that for a bit.

From what I understand, the purpose of FromStatus is to convert status.Status to a particular type of service error; or fallback to status.Error if there isn't one available.

An incompatibility issue would occur if a user
(1) relied on the error message details (.Error()) or
(2) tried to cast the result to a status.Error

Both seem unlikely, but definitely technically possible.

👍 I can add a warning to the release notes.

What about out of range and unauthenticated? Should we do those now too or wait?

Good question. I'm not sure tbh. Doing it now batches the "breaking" changes; but we might also never change this.

Generally, I understand this method to act as "try to parse this status to a typed error so I can extract error details". If the status cannot be converted, I wouldn't expect users to use/expect the status.Error since it doesn't add anything over status.Status. But they still might ...