We (rackspace) have had great success with Fog, jclouds, pkgcloud, libcloud, and other multi-cloud toolkits. For openstack / Rackspace cloud we also have php-opencloud, openstack.net and pyrax (which uses the python-XXXX clients from openstack core).
It definitely is a fine line to walk; a good abstraction though means that you can use the most common features easily and float through providers, but you have access to the advanced features if you need or want them.
Commonly those advanced features (on a provider level) mean a greater level of vendor lock-in which is why they may not make sense to expose in the higher level abstraction.
You're right to think it's impossible to keep up; even getting this far, I've heard rumors and tremors about up-coming V3 APIs in several areas. I'm sure by the time V3 support is contributed, V4 will be on the drawing board. Thankfully, the general availability of a V3 API does not usually preclude the continuing support for V2.
All we can do is deliver value to our users in a consumable format while trying to remain aware of any changes in our ecosystem.
While we were getting Pathwright launched, we contributed a whole lot to boto, which is primarily (but not exclusively) catered to AWS. It grew Eucalyptus (not a huge jump) and Google Compute support, but they were badly documented/tested and still seem to see much less maintenance than the AWS stuff. The situation has improved slightly as Amazon has hired a few more guys to help the maintainer make boto awesome, but they're still playing catchup with the core competency (AWS). This isn't to talk badly of boto, it's more to illustrate the magnitude of the task of keeping up with even one aggressively developing vendor.
I worry that these "mega-cloud-libs" are the wrong approach. The OpenStack stuff will probably end up with excellent support, but the others are likely to see much less attention, documentation, maintenance, help. The neglected areas of the codebase get to be embarrassing and not up to the quality standards of the primary focus (OpenStack in this case). Perhaps they end up falling behind in API versions for some vendors, limiting their utility.
This is definitely not to poo-poo the effort, I think it's a really neat ideal. Personally, I'd love to see them focus on making a kick ass OpenStack Go API with top notch documentation and tests, and leave the other services to their respective communities. That alone would be noteworthy.