Sorry that I wasn't clear, I meant what do you like about the Chicken sql-de-lite egg.
Oh. I don't, excecpt as a proof of concept.
Thus I envision a Scheme RDBMS interface at the sql-de-lite level that's database agnostic, but more refined than sql-de-lite.
In my view, database agnosticism is unimportant. Vanishingly few projects change their databases in midstream, and there is always a lot of pain in it no matter what library you are using.
(dynamic typing is not always your friend),
I agree, but that's hardly an argument calculated to convince Schemers. Although most tables are de facto statically typed, there are real advantages to manifest typing. One case that came up: an RDF triple store. In a triple (S, P, O), S and P are always URIs and can be statically typed String. However, O can be another URI, or it can be a simple value: arious kinds of numbers, dates, strings, etc. (In general, though not invariably, the identity of P determines the type of O.)
A natural (though certainly not the most efficient) representation then is as a four-column table, S, P, O, and Otype. However, in a statically typed database, the table must be divided into multipletables solely on whether O is (from the database perspective) a string, a number, a date, or what not. They could all be strings, of course, but only at the cost of being able to treat the numbers and dates as such on the database side.
On top of this level of library, I want one or more interfaces that are SQL dialect and database feature hiding, so you're not as directly composing SQL query strings in one way or another.