Seems to me abls::Status and media::TypedStatus (and the associated StatusOr classes) both address two somewhat orthogonal concerns:
1. Providing a convenient wrapper for a result type OR error, with programming patterns to propagate the error if necessary.
2. Providing a common set of errors and an extension mechanism to attach context to them.
These aren't completely orthogonal, since once you propagate the error you must think about how other layers handle it, which is where the common error set comes in.
To address concern (2), absl::Status chose to bake a quite prescriptive error set and extension mechanism into the same class that provides (1), presumably because for the original usage in Google it was very desirable to enforce consistency in error handling across a wide codebase.(That's just my guess, I haven't spelunked through docs for the history of this decision or anything.) It uses the philosophy that higher layers should recognize the "canonical errors" and know how to handle them, so that's the only error codes that should propagate, and extension data is used both to add generic context information (eg. for logging) and to backdoor in error-specific information that cooperating higher layers might recognize and act upon.
media::TypedStatus instead makes the error set more flexible to enable the local error handling pattern Frank described, but adds a more detailed list of extension data to propagate to other layers including the ability to wrap a TypedStatus in another one (presumably with a more generic error code useful to the next layer up) and attach the original status in the extension data.
(1) is widely useful throughout Chrome, and it would be good to have a standardized class to do this. The media::TypedStatus approach of allowing different error sets in local code seems more useful for the various users in Chrome.
I think the requirements of (2) are more contentious because it depends a lot on how the extension data will be used. For instance media::TypedStatus includes a rich set of context information (code location, stack frames) so I assume there's a consumer that hooks all this up to error reporting. Is that precise method of error reporting useful outside media?
I wonder if we should split these concerns and use an evolution of media::TypedStatus as the base status class (including only status code, message, and list of wrapped "causes") and allow different users (such as media) to extend it with specific extension data. An absl::Status interop class for the third-party boundary could be one of those extensions, if needed.
That would let us immediately reign in the number of Status re-implementations without blocking on the more contentious extension data design.