(* OTOH, I view the db itself as implementation detail - maybe the data is persistent in a database or maybe its some stuff I happen to have in memory and I don't need to save. I don't care. So long as I have powerful set operations that work on the tuples in the collections. *)

Databases are about managing collections, period. Whether you save them or not is another matter. (Vendor support for virtual or temp tables varies. That is not my fault.)

Anyhow, as long as you don't distinguish between "types" of collections, then we are pretty much saying the same thing. Whether we store the collection or keep it in a temporary buffer only (such as RAM) is also an "implementation detail". One should not have to alter their collection interface if they decide to "save" a collection for whatever reason, and visa versa (beyond setting an attribute or two).