You'd use a macro to do this, as Rust doesn't allow for custom operators. If you really, actually want an ¿ operator, you'll need to design and write an RFC proposing the change, and then convince the core team to adopt it.
If this happens, I think it imperative that it be made a prefix operator.
I would suggest using a macro that emphasizes this structure, rather than hiding it in short-circuiting.
The thing that makes ? great is that you can mostly ignore it when you're trying to understand what a function does. But that's very much not true of the proposed ¿, since if you ignore it then many of the paths look silly.
The let-else statement, is powerful, for the case of the book is a good use case, but I think if we need to use several functions to test, would be better the macro or a similar one.
If a function to read, needs several steps like the book, there could be good use the let-else, just to be able easily read the intentions of the code.
I think is a great idea, for things like this, instead look a pure code solution, a macro that is able to synthesize the concept
Have you seen the ControlFlow enum? Its semantics are less specific, so it's useful in cases where shortcircuiting isn't necessarily an error. It also works with the ? operator.
If my history knowledge is correct, before the ? operator existed, Rust used a macro for it called try!. The point being, defining a macro works well for this sort of thing.
Note that the way you use the try! macro was completely different from the macro I'm proposing here. Yes, one could make a yrt! macro that just flips the match arms, and it'd be easy to do so, but I'm intentionally suggesting not doing that.