Every modal dialog plugin I’ve seen takes the following approach: try to anticipate the ways people will use it and provide configuration options accordingly. The problem is that as soon as you require anything the developer didn’t anticipate, the plugin becomes useless (or you start messing with the source). If you’ve read Spolsky’s essay, you’ll recognize this as a leaky abstraction.
Veneer tries to minimize leakiness by doing the absolute minimum while making it simple to add anything you need (as in my third example).
I'm not following how or why this is a leaky abstraction. My understanding of leaky abstraction is an interface or API that fails to mask the implementation details of it's functionality.
A library that does more than you want, without addressing your specific (and probably custom) application needs seems inevitable. I don't think that's a bad thing and I don't see how this library is any more insulated from that problem.
I’m referring to leakage in the other direction. Think of a lightbox library as a layer over JavaScript’s API. When working with a library you can either use the configuration options provided or just go back down a layer. The space spanned by the configuration options is inevitably smaller than the full space of possibilities you have when working at the JavaScript level, so it’s likely that you have to go back down to JavaScript anyway. That’s why I prefer working with libraries with less friction between the layers over those that try to anticipate a use case but are useless as soon as you need something different. As phzbOx mentioned the Django authentication system is another example.
Veneer tries to minimize leakiness by doing the absolute minimum while making it simple to add anything you need (as in my third example).