Not true. Exception hierarchies solve this problem.

Nope. Exception hierarchies don't even come close to solving that problem because the superclass or interface author usually didn't anticipate your need and define the method signature in a way that would be useful with exception hierarchies.

So you're inheriting a class not within your own application, but written outside of your application. Composition might work better in this case.

Nope. Composition doesn't help when you have to implement an existing interface in order to make some API work.

If you're implementing an existing interface for that reason, it's because something else is going to be calling you. In which case throwing an exception that they don't expect is probably a bad idea, and relying on it just flowing through their code back to you is basically relying on implementation details in many cases.

No, that's not how it usually works in practice. Typically where this becomes a problem is in using an existing library as a middle layer in your application code. So you could catch your own additional exceptions, but the interface method signatures don't allow for that. Hence the need for ugly hacks like wrapping the checked exception in a runtime exception, then catching that and extracting the original exception. A real mess, but still better than the alternative of forking and modifying the library.

That is exactly my point - when you have a middle layer written by someone else sandwiched between parts of your code, assuming that any random exception you can throw will flow through (or, for that matter, that there even is a "through" in many cases - e.g. if the library makes some part async) - is relying on implementation details of said code.