The first case, in essence like doing a UNION (though in Arjun's case the queries were separated by logic that I don't think would've mapped to a single query-with-UNION).
To add items without doing a query you'd still need to use template::multirow append.
I don't mind that particularly, after all the db_ prefix indicates that db_multirow hits the database and we should preserve that.
What *does* bother me somewhat, again falling in the "rough edges around ATS integration with the ACS" bucket, is the fact that the parameter parsing and general namespace/pseudo-object dispatch style of coding in the template engine results in an API which is of a different style than everything else in the toolkit.
"better" or "worse" not being the issue so much as simply "different". I worship the gods "consistency" and "uniformity".
It is "worse" in one respect in that there's damned little error checking in the template parameter parsing code. Mistyping a name in a dash-style parameter results in silent failure.
