It's been an interesting experience, deriving the simplest language I could come up with that suffices for this purpose. It's certainly more complex than it once was, but still -- the reasonably full language definition fits in a handful of screens. It's not *quite* as simple as Scheme, but it's well up there.
The end result is a bit surprising, with a couple of aspects that emerged organically as I developed. One is the fact that it's a very pure functional language: that wasn't an original design goal, but after a while, it became clear that there was no good reason *not* to go for pure-functional, and all the usual arguments in favor apply here. The other is the incredibly strange way Querki handles function parameters, behaving more like macros than conventional functions. I keep feeling like this *surely* must be wrong, since no other language I know works this way, but it's clearly optimal for the way Querki thinks about data.
(An open question is whether QL should be considered a DSL. It kind of is, in somewhat the same way that SQL is: the domain is "data transformation". I have trouble considering that a "domain", but there you go.)
Anyway, I've written up a first-draft guide to the language, which can be found here. I'm unlikely to change any major aspects of the language at this point -- this syntax was evolved through a lot of careful thought about how one works in Querki -- but questions and comments would be quite welcome...