It seems that you bunch too many error-handling issues into the single bucket. There cannot be a single “error handling facility that meets all the needs and suits everyone”. Let’s take your example. If you have errors that need to be tracked and shown in UI then you clearly do not need any kind of stack trace (since you are not going to show it to the user), so it is a good case for use of sealed classes: they are explicit and composable.

Easy stack unwinding is also not a big problem— with Kotlin and its inline functions you can design a very convenient DSL that fits your domain. It is not going to as concise as ? in Rust, but I’m sure you can leave with something more verbose, but clear and explicit, as .orElse { return it } .