That's an interesting development. I've worked with Deferred in Python and Promise in JavaScript and they both follow the same model where the Future can be in one of three states: pending, successful (resolved), or failed (errored). There are (chains of) callbacks associated with both the successful and the failure state. If an error occurs in a success handler, the flow switches to the error handlers. An error handler can then deal with the error and the flow switches back to the normal callbacks, otherwise the next error handler is called.
The net result of this is that the error handling becomes asynchronous. The way the async/await discussion is presented in the final proposal (in particular the "error handling problem") seems to indicate that error handling for Rust futures should be synchronous. That is, you get a Future<Result>, you await it, you look at the error, and then you continue with your work.
I touched upon the same point here: