That shouldn't and mustn't require much effort for anything but the specific and the exotic. In other words, it should be possible to use the mandatory features of a query language for normal queries like "retrieve by ID" or "find by property or child property." A basic driver and standardized API should be usable for CRUD operations and elementary finder queries. Optional features and specific APIs should only be required for features that are unique to the database or database type such as the distance of two records along a graph.
This doesn't need to be a perfect effort. Certainly no RDBMS vendor's dreams have been complete without their individual incompatible extensions and quirks that lock in customers. The standard just needs to be "good enough" to make people feel like they could switch databases. In some ways, this is more important for the so-called polyglot persistence of NewDB. I may start out with a document database problem that seems made for MongoDB when a new requirement makes the problem just fit a graph database like Neo4j so much better.
A common denominator for queriesIn this polyglot nature lies the problem. A query language designed for a graph database isn't necessarily attuned for a document database or a key-value pair structure. In many cases this is OK because most of the time we're querying for simple items. Most of these databases support some form of hierarchical query (that is, I want all parents, grandparents, or great-grandparents of red-headed children or all customers who ordered any product that contained a particular model of transistor no matter how deeply embedded), where SQL does not. Obviously, a NewDB standard query language should support that. A standard need not always say "must"; it can say "if possible."
Last year, there was a ray of hope: A couple of Microsoft researchers noted that NoSQL needed standards. This sparked a renewed effort to implement UnQL and LINQ support for MongoDB, which covered both the point-to-point nature of platform support and an attempt at a basic unified query language. Spring Data is unifying the Java world around a CRUD interface, however, so we're still in the mud. UnQL doesn't seem to have legs. What about Neo4j and LINQ?
What's needed now is for the NoSQL vendors (10gen, Cloudbase, and so on), interested parties (such as SpringSource, Red Hat, Microsoft, and IBM), and various projects to come together, take some of these separate efforts, and propose standards. First, define the query level. Then define the connector standards.