I'm not sure what your point is. If a function has a "unitary" return type (not, say, a list of possible return types out of which one is selected) then obviously it always returns a value of that type.
You could probably invent a kind of function that had a list of possible return types. Then anyone who called it would have to deal with those possibilities.
It all comes to the same thing in the end. Sum types and pattern matching are a very good system for expressing this functionality.
It's conceivable that a compiler would throw away the Either type information and just generate separate code for the different ways the function might return. Ultimately, though, I suppose it would end up calling a continuation, since the function has to "return" somehow.
> IMO this counts as a kind of out-of-band arrangement because it doesn't involve using one of the normal return values to signal error.
My point is that if you're returning an algebraic data type Result that encodes Ok(val) or NotOk(_), you are using one of the normal return values, because the function always returns a Result. The whole purpose of the construct seems to me to be bringing the error case handling into band.
In-band signalling is messier than out-of-band signalling, so I see out-of-band as the goal. If you look at the various approaches to the semipredicate problem on that Wikipedia page, it looks like, historically, we started out with awkward in-band solutions and the evolution is towards the clarity offered by expanding the return type to send errors out-of-band.
I mentioned this previously on HN, and maybe that earlier comment will clarify what I'm talking about: https://news.ycombinator.com/item?id=18766478
pjc50's way of applying the terms to flow of control is a somewhat different thing.
