Checked errors are not categorically better than runtime exceptions. There are lots of things that should never be checked exceptions: division by zero, illegal array access, OOM, and everything that can't be (at least not locally) recovered from.
That's why Kotlin's philosophy is and has for a long time been "use values for expected and recoverable errors, runtime exceptions for unexpected and unrecoverable conditions", see: https://elizarov.medium.com/kotlin-and-exceptions-8062f589d0...
> Except for the whole Kotlin standard library.
I'm not sure what you mean. Most kotlin stdlib functions that can fail have some sort of "...orNull" variant to be used when you're not sure you're going to get something back, and there's "runCatching" which will wrap any exceptions in a Result type.
Result is part of the stdlib, so you don't have to use any library, although some people (me included) prefer Either. If/when they introduce Rich Errors, it's going to be semantically almost equivalent to Either, except you get somewhat improved ergonomics, so it's not really a paradigm shift.
> Ultimately, there is no difference because Result<T, Error> and T func() throws Exception. One is not superior to the other. What it comes down to for me is whether a language has support for checked errors or not, and Kotlin does not.
I don't understand how those two sentences don't contradict each other. Kotlin has support for Result<T> (stdlib) or Either<E, T> (from libraries like Arrow). Since you're agreeing that this is equivalent to checked exceptions I don't understand how you can claim that Kotlin doesn't support checked errors. It supports them just as well as Java does, it just has a different philosophy around it. (I guess the one point that I'll concede is that it can cause issues when interfacing with Java code and it would be nice if Kotlin had some better ergonomics around automatically inferring errors from Java library code the way it does for nullability checks; but in practice this hasn't been a big issue for me).
FWIW, I disagree that there isn't a big distinction. If the exception is part of the regular type, it is a value and it can be manipulated like any other value, making it very easy to write all sorts of code that manipulates exceptions. Of course, you could eventually write enough machinery so that you get the same power also with checked exceptions, but that just makes the language more complicated for questionable gain. And in any case, Java doesn't do that.
The Scala discussion you're linking is certainly interesting, but it's cutting-edge PL research (effect systems). I'm not sure how this matters in a discussion of tradeoffs between Java and Kotlin today.