You've made "SQL injection" impossible by inventing "albertzeyerql", which will inevitably be vulnerable to "AZQL injection". Many of the NoSQL's have similar problems; expect to hear more about them in Blackhat presentations yet to come.
It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive; meanwhile, the proper defense against SQLI (being mindful about query inputs, and using the framework to abstract and normalize dynamic queries) is available today and works well.
I am not really talking about a language at all (at least not on a byte-alphabet).
Maybe we misunderstood a bit. For example, take a look at the [new Redis 2.0 protocol](http://redis.io/topics/protocol). In this protocol, injections are simply impossible. This may not be the best example because you don't really have more complicated queries but you could just do the same for tree-like structures.
I think you're wrong, both in your general point and about the possibility about Redis query injection; unfortunately, you're wrong in ways I'm not at liberty to correct. I can only ask that you take my word for it that you need to be as mindful with the code that constructs Redis keys as you do with code that concatenates SQL queries. And, as with SQL, much (perhaps most) production-quality code isn't susceptible to attack; but the lines that are tend to blindside you.
I don't see why you couldn't inject a CR LF? Sure it might not be that dangerous (although it could be depending on what validation the server does on # of args), but you're still modifying the query.
It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive; meanwhile, the proper defense against SQLI (being mindful about query inputs, and using the framework to abstract and normalize dynamic queries) is available today and works well.