The "info" state somewhat misses real life use cases and ignores learned
behavior on developer site. To name it, everything returned "informational"
on such a channel is easily discarded as noise, as it adds significant
bloat on each call site to handle it.

At the same time, it builds on the (wrong) assumption that there is only a
single non-fatal error or warning in a single function call.

That be said, trace information does not belong mixed in with status
information which *require* handling, ever. The only proper way to handle
trace infos across components is by error reporting callbacks, anything
else looses too much context to be of any real use.

Treating the combination of `status && !value` as an error conflicts with
real world APIs which have to distinguish between "please retry" and "fatal
error". Both carry status codes, neither carries a value yet, but only one
is an error.

When using classic error codes with return parameters, `[[nodiscard]]` is
suitable to enforce handling at the call site, when mixing value and status
in a single return value, status code handling is likely to be missed by
accident. And in a way which is quite difficult to enforce at compile time.

I'm not quite sure on this point, but I also believe that interface is a
bad substitute for interfaces which returned value "by value" in raw form
(with use of exceptions), as it breaks copy ellision by that temporary
wrapping even if the status code is intentionally discarded at the call
site, due to error state being an impossibility in a fully controlled
environment.

Then there is also feedback from practical application of a similar pattern:

Strict typing is essential, even for return values. Especially if the
actual return value is just a primitive type wrapped in a future, stored
for consumption in a different context, and mix-ups could easily occur
otherwise. So you end up declaring return types with identical layouts as
you go, at the cost of 5 LoC. Using your proposed template simply doesn't
work, as you suddenly require more care to prevent specializations from
being accidentally casted between each other, when inheriting publicly.

Last but not least: the proposal is coming a bit late to the party. Unified
error handling is something which would had been required before libraries
had established their own standard ways. Now it falls in the line of "There
are 10 competing standards. That's too many, let's design one which covers
everyone's needs. Now there are 11 competing standards." There is no chance
of unifying that aspect in the ecosystem retroactively.


>
>