I like the general idea (not a fan of the syntax but whatever). The one thing I'm not seeing is non-exhaustive error types. For example, in a library, you likely want to say "these errors are known to be possible, and some errors may be added in the future". Without non-exhaustive error types, this would mostly be useful exclusively in applications, not libraries. Of course, syntax-wise, you can just do (E1, E2, ...) or something to mark it non-exhaustive (if you were to add this to the language directly).
Either way, I agree that defining errors is needlessly extraordinarily verbose. I'm tempted to make a simple one-line macro to union a bunch of error types into an enum. (or use this library since I misread this as a language proposal lol) This, of course, falls apart when a function might use the same error type for multiple errors, or if it uses custom errors with no inner errors, but those cases are what thiserror is for.