* SQL not being relational algebra
* SQL implementations being incompatible
Both are real but I have not experienced either of these being a problem in real usage. Despite the problems caused by NULLs and that SQL allows duplicates I do not think the alternative would be better for real world programming. And the incompatibilities are avoided by picking one database per project and sticking with it.
Even if you reduce it to its most basic issues, you missed a third: Incompleteness of implementations.
If you have not experienced problems as a result of these core issues, it honestly makes me feel you must not have a lot of experience -- at least not in diverse projects and environments.
That you think picking one database is some sort of viable solution in the general case amplifies that feeling. That is so often simply not an option, and even where supporting only one database at a time is an option, you absolutely cannot guarantee that you will not have to migrate later. I've been through that pain many times, it is a real-world problem.
I honestly think you should look at the database just like any other piece of your code, you cannot just replace GTK with WX Widgets and except there to be no migration work. And most of these differences between databases have nothing to do with SQL, but rather databases not implementing it correctly for legacy reasons.
I would not expect a new database query language or NoSQL databases to do this better.
