Actually, my impression is that the discussion got derailed from „Let's add a simple type alias so people don't have to type Result<_, Box<dyn Error + Send + Sync>> and forget the Send + Sync part half the time“ to „Let's design a new type that hides some details about what it really is and captures backtraces“.
I think the first is blocked only on consensus to go ahead and bikeshed the name.
The second is probably blocked on bunch of different things (discussion if it should capture backtraces, under what circumstances) and one of these things is possibly specialization as such type should implement the Error trait, but should not wrap it into another level of dynamiciness in its From implementation (eg. specializing From<Self> to be identity).
@vorner I just added a type along those sorts of lines to the Abscissa framework today (in order to remove failure and switch to pure std::error::Error):
Note that there have been some recent discussions about trying to improve error handling in std, and in particular, any proposed solution here should provide forward-compatibility with further extensions such as contexts.
Various different places. Take a look at the anyhow and thiserror crates, the proposal for a core Error trait shared among several error-handling crates, and several recent discussions on the /r/rust reddit findable with "error" in the subject.
There isn't consensus on everything we'd want to change, but there seems to be a decent sentiment towards getting the common elements provided by most error libraries into std (and getting some of those bits into core).