[MikeCodeAwesome]

Given your scenario, you are indeed correct: throwing implementation-specific exceptions leaks internal details and further couples clients of the API. Can you imagine using such an API which forces you to continually handle new exceptions that arise from new implementations? As you suggest, it's better to create an exception for the API which then wraps the underlying exception. I would not go so far as to create a family or hierarchy of API exceptions unless there's a need to communicate each of them individually.

What usually happens in practice is a combination of none and all the above. A bit of a mess, really.