I'm not sure what you mean. SQL Databases have varying feature-sets already and SQL copes just fine. A "NoSQL" backend would simply be yet another type of database, lining up with e.g. MySQL and Postgres.

It's just a matter of applying the verbs (SELECT, CREATE, INSERT, UPDATE) in a meaningful way.

The individual stores could even extend the language to a degree, just like the RDBMS flavours do today. The important wins would be a common baseline (select foo from bar), a standarized way for human interaction (adhoc queries in a console are very useful) and a much easier migration path from traditional RDBMs.

How well does SQL deal with conflicting data being returned from retrieval operation?

Again I wonder what you mean?

If you're referring to versioned stores, or stores with particular semantics, then I'd imagine things like that to be simply embedded into the response. I.e. all tables returned by a select-statement could simply contain an additional column containing the tuple version. The user can then deal with that meta-data using the usual, time-tested SQL machinery (select .. where version=, group by, etc.)

Yes, this means every store needs slightly different treatment. But that's no different to how we treat RDBMs today - a common baseline with variance in the more specific features (column-types, indexes, triggers etc.).

I certainly hope that document-store developers do not take the lazy route and prematurely converge on a standard like SQL.

That's a strange wish to have as it only makes life harder for everyone. I don't see anything bad about SQL (the language) that would prevent it from taking this role.

Moreover the query language doesn't need to have ties into the underlying implementation - it's merely a common vocabulary.

SQL seems like a natural choice due to its ubiquity.

LINQ, in my book, is an ORM and operates at a different level of abstraction. Pig and HiveQL otoh are exactly what I have in mind - SQL dialects.