While I think your argument has some resonance, I also think it is good to have a specific checked exception type because the programmer can scope a set of deleterious events that they have anticipated. I think perhaps a CheckedException class would be a good starting point from which a library of such events can be built for one’s deployed module, and any users of one’s module could easily navigate their way through one’s library of anticipated exceptions if they wanted to.
The main gist of my suggestion was in finding an acceptable solution to situations where a developer didn’t want to deal with a particular problematic event that the developer of a dependent module had anticipated.
Likewise, if one creates a method that one intends dependent modules to call, I think it would be good if the developers of those dependent modules could control whether they intend to deal with the exception, or whether they prefer to ignore it and pass this responsibility onto modules that are dependent on theirs in turn.
In my suggestion, if other developers are able to ignore an exception from one’s library, there would be less likelihood of these other developers burying checked exceptions within unchecked ones because at some point, every checked exception might be dealt with appropriately; not every exception would need to be dealt with by the next dependent module, and so the necessity of dealing with any particular checked exception can be deferred to an appropriate handler module and the developers of modules between these can get on with their lives.
I think this type of flexibility would generally be appreciated and eventually adopted by Kotlin developers if it were available. Kotlin might also recruit those Java deveopers that are waiting for a checked exception mechanism in Kotlin.