Google's util::Status and util::StatusOr are actually quite flexible. While the generic error space is recommended for most work (and really, rather a lot fits in that space), it does support the notion of other error spaces like POSIX or Windows. At Google† I do quite a bit of interacting with the kernel, so my code makes fairly heavy use of the POSIX space.

That said, in the vast majority of cases any error I might be reporting from the POSIX space can be just as if not more usefully expressed (for the consuming software) using one of those ~15 generic codes. If their semantics are properly adhered to, those codes give good guidance on when an operation is guaranteed to have failed (but can be retried), when it's guaranteed to have failed (but cannot be retried without changing the request), when its fate is unknown, and when it has succeeded. In many cases this allows for generic error handling policies that fit a given application well. With enormous error spaces that is much more challenging.

In the cases where the underlying error deliveries clear value and I'm communicating across an abstraction boundary (I find the intersection of these is relatively rare), the Status type supports (albeit somewhat awkwardly) nesting. That allows the basic error to be one of the canonical types and the precise error to be communicated as a nested Status.

† I work on Google Compute Engine's on-host network devices and dataplane.