If you want this function to return an error that encompasses any of the sub-error types you are forced to write the most incredible amount of boilerplate that I've ever seen in a language. You need to define a composite error type and then implement all the required traits for it.
I'm not sure how some people avoid this situation, but it's an incredibly common scenario and the only reasonable solution is to use a library like anyhow. Defining your own errors is also heavily boilerplate prone giving rise to things like thiserror.
Why these third party libraries are not made into first class language features is beyond me, but it is an example of very poor design and is typical of what I mean. Rust implemented a solid error handling core, but then just didn't bother with the things that would make the error handling actually good. Fancy over pragmatic.
I would say a language like Go is well designed in that it has an overall design philosophy and you can see that throughout the language, including in the limitations which are often intentionally chosen. One part of their philosophy that I really appreciate is their intention to make the language pragmatic in industry settings, and making typical things obvious to newcomers is a huge part of that.
Even if your solution is macros (which may be ok, but can also make the underlying generated code more opaque), it should be part of the standard library and part of the language manual. Making things the "officially approved way of handling a problem" has benefits beyond newcomers too, it gives the entire language more consistency resulting in a far more cohesive design.