"And the other examples aren't really leaks, just performance disadvantages." I don't know what your particular area of expertise is, but in my experience, per

"And the other examples aren't really leaks, just performance disadvantages." I don't know what your particular area of expertise is, but in my experience, performance is the reason that most abstractions fail, because there are a lot of cases where I can't simply accept the poor performance provided by the abstraction. All of a sudden I have to start worrying about what is going on behind that interface so that I can use the interface in an optimal way. And once you have to start worrying about what is behind the interface, you're in leaky interface territory. Here's my favourite example - allocators. Is my memory manager smart enough to detect that I'm allocating and disallocating a bunch of buffers of the same size, and will decide to keep some in cache for me? Can it see that I am doing a lot of allocs and frees from one thread, so it uses a special non-thread allocator for these allocs? These can be big wins in performance, and I can't leave them on the table. Some allocators do these things, but there is generally no way of knowing just by looking at the API. So you have to start hoping that the documentation explains what is being done behind the scenes, or that you have the source code, or be prepared to do some performance tests. Here's another example where an API works hard to hide a performance leak - OpenGL. Internally most OpenGL ES implementations hold texture buffers in a tiled format. This allows the GPU to copy the texture to the screen at a similar speed, no matter the orientation of the texture. If this wasn't done, you would get massive differences in performance if you rotate a texture by 90 degrees, due to memory paging issues. But with tiling this is not the case, performance is nearly constant. But this type of sensitivity to performance-based abstraction leakage is rare (and indeed creates another leak - you now need to be aware that there are potentially two copies of your texture in the system - the one you write into and the one that is actually being used by the GPU). In my opinion it is nearly impossible to create an abstraction that doesn't leak implementation information. This is not to say that abstractions are worthless, but just to highlight that abstractions need to anticipate this and provide the tools to make dealing with the consequences a bit easier.