I stand by "an ORM should work as just a query generator and let you skip any object layer when you want to", "an ORM should be able to let you feed the object layer data from your own query" and "an ORM should let you mix and match programmatic query generation and literals to as granular an extent as possible" being table stakes if you have developers who actually like SQL.

There are a bunch of things I hate about the DBIx::Class stack (most of which were my poor decisions to begin with) but it gets those right. Example:

    $schema->resultset('Foo')
           ->where({ bar => $bar })
           ->update({
             baz => \'CASE quux WHEN 0 THEN baz - 1 ELSE baz + 1 END'
           });

would generate (the \'..' means 'reference to a scalar' in perl)

    UPDATE foo
    SET baz = CASE quux WHEN 0 THEN baz - 1 ELSE baz + 1 END
    WHERE bar => ?

and duplicate the relevant SQL generation guts across to a statically typed language wouldn't be horrible ... but every time I start trying to figure out how to get useful per-select-list types for query returns I end up tying myself in knots (easy enough for a simple-CRUD oriented ORM but once you're looking at expressions in SELECT that are query-specific it starts getting gnarly).

I think you may be right about Nim though and thank you for reminding me that I really need to get back to playing with that :)

(obligatory perl disclaimer - if you don't like perl, that's entirely fair, but in that case please steal the good parts of my/the rest of the DBIx::Class/SQL::Abstract team's ideas into your language of choice because developers who don't like perl deserve nice things too)