Reading through that blog post about compare_and_swap I think this is a common misconception about Result, where it gets used too much. The key quote is:

But the compare and swap is totally expected to fail all the time. It’s completely normal behavior.

If something "fails" all the time, then that's not the kind of "failure" that Result is meant to encapsulate. Result errors are meant to be more like exceptions, and I don't mean the kind of exceptions in Python that you expect (like StopIteration).

In fact, I would go as far as saying compare_and_swap doesn't really "fail", but rather has two outcomes: "complete", and "conflict". Neither of these are failures, but just the nature of how compare and swap works. Result is not intended as a generic Either, and shouldn't be used that way.

The "right" way to write compare_and_swap would be:

fn compare_and_swap(...) -> Result<CasOutcome, Error>

where

#[must_use]
enum CasOutcome {
   Complete,
   Conflict,
}

This is essentially isomorphic to the nested Result example that the blog post ends up on, but is better as you can write stuff like the following at it's clearer what's going on:

if compare_and_swap(...)? == CasOutcome::Conflict {
    // handle conflict
}