> 1) Nicer syntax for SQL than strings
>
> Too complicated for me, that's for sure.

It doesn't need to be part of the low-level interface, but I'd consider
it a must as a higher-level library. Writing SQL by hand is painful and
extremely bug-prone, and gets unwieldier really fast as application size
grows and you deal with sub-selects, migrations and other real-world
stuff. The quoting and lack of reflection/meta-programming are obvious
pain points. And the fact that you can't compose queries and factor out
common sub-queries flies against the face of decades of decomposing all
programs into subroutines.

> I'm not a big believer in porting
> applications across databases anyway: it hardly ever happens.

It's very nice for open source applications to be database-agnostic (at
least among MySQL/Postgres/SQLite). It's a big relief when you can go
with SQLite for local dev, and for deployment it's nice to be able to
re-use whatever DB is already installed on the server.

> Making
> higher-level libraries work on any database is a more plausible goal, but
> extremely hard.

As with GUI toolkits, it's manageable if you cut out all inessential
features. I'd still love to have a close-to-ANSI SQL DSL that handles
all the portability hacks behind the scenes.