Java's checked exceptions experiment was very painful in various ways that directly exposing an error state as part of the return value is not so I wouldn't quite characterize this as "Everything old is new again."
The first big thing is that Java, especially in the days of when checked exceptions were a really big thing and less so in modern Java, was really into a certain kind of inheritance and interface design that didn't play well with error states and focused on the happy path. It is very difficult to make Java-esque interfaces that play well with checked exceptions because they like to abstract across network calls, in-memory structures, filesystem operations, and other side effectful tasks that have very different exception structures. An interface might have a single `writeData` method that might be backed by alternatively a write into an in-memory dictionary, a filesystem key-value store, a stateless REST API, or a bidirectional WebSocket channel which all have wildly different exceptions that can occur.
The second thing is that because checked exceptions were not actual return values but rather had their own special channel, they often did not play well with other Java API decisions such as e.g. streams or anything with `Runnable` that involved essentially the equivalent of a higher-order function (a function that takes as an argument another function). If e.g. you had something you wanted to call in a `Stream.map` that threw a checked exception, you couldn't use it, even if you notated in the enclosing method that you were throwing a checked exception because there was no way of telling `Stream.map` "if the function being `map`ed throws an exception rethrow it" which arose because checked exceptions weren't actual return values and therefore couldn't be manipulated the same way. You could get around it, but would have to resort to some shenanigans that would need to be repeated every time this issue came up for another API.
On the other hand if this wasn't a checked exception but was directly a part o the return value of a function, it would be trivial to handle this through the usual generics that Java has. And that is what something like `Result` accomplishes.
IMHO the mapping issue comes from functions not being first class, so all types require Functor-like interfaces which are needlessly verbose. Splitting these is not semantically different than a function that returns a value vs a function that returns a Result.
I have little love for Java, but explicitly typed checked exceptions are something I miss frequently in other languages.
No I think it's a deeper issue than that. In particular because exceptions aren't a return value, you can't make a function generic over both values and exceptions at the same time. This would persist even with first class functions.
If you want to be generic over exceptions, you have to throw an exception. It would be nice to have e.g. a single `map` method that appropriately throws an exception when the function that is called throws a function and one that doesn't throw an exception when the function that is called throws a function. But as it stands, if you want to be able to throw a checked exception at all, you have to mark that your higher order function throws checked exceptions, even if you would prefer to be more generic so that e.g. you only throw a checked exception if your function that is called throws a checked exception.
Thr only reason this works in other languages is because they’ve made the choice to return objects that represent success+value or error and then added explicit syntax to support those types. That means function signatures put the error in the return type instead of a separate exception channel, but that’s really only a syntactic difference. It’s otherwise isomorphic.