Comment by convolvatron

this is an unfortunate take. btrees do not imply bags. in fact extreme bagginess can be a problem when all the keys in your page are the same. lets take this from the point of view of the user, we can certainly understand that some domain models really want to be set like, and other ones baggy.

if the base domain is sets we do get a lot of nice constraints, particularly with semantics around projections and if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.

if we want to support sets in bag-land, we could imagine an extension which support 'row unique' on insertion. or we can use a 'unique results' post-filter. so there are paths, but its a lot less clear in a SQL context.

you insist that your data demands bags. I really prefer to work in sets and bagginess is always just a source of crappy errors for me. shouldn't we really support usable models for both regardless of the underlying storage?