"first-class support for returning errors and propagating them" certainly sounds like exceptions! In fact, the compiler can even emit special tables that let the runtime completely skip over stack frames that don't need to do any cleanup during that propagation step!

Some languages have even innovated new kinds of exceptions that you can throw but that you are admonished should almost certainly never be caught.

Unfortunately even this is also better for tool support, a problem that using a bunch of macros solves. It's cool and good when a variable gets declared inside the guts of some macro expansion (and--critically--escapes those guts).

Its not the same. You have to explicitly declare the errors and if you want to ignore/propagate them, you have to do so explicitly as well.

You cant invoke a function and pretend it'll never fail.

Also, try/catch with long try blocks and a the error handling at the very end is just bad. Which of the statements in the try is throwing? Even multiple perhaps? Each should be handled individually and immediately

Deliberately more verbose. Not sure how it'd be slower. And only a tiny bit more verbose if the language has nice keywords/syntax for you to use. The point is you want to be explicit when you're choosing to ignore an error.