> btrees do not imply bags.

Correct.

> you insist that your data demands bags.

No, I insist that real data needs both. You can bias the language/engine in one way or other.

The underlying problem is that once you say:

> if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.

Then it means that this is second-class.

The main gripe I have, is that the relational model has this beautiful promise of "make the storage invisible" but need to have a coherent semantics about the data.

If you say "2 identical values/rows can't exist" then we adding the same problem that all the rdbms has: None implement the relational model, and none can deal with "relation on relations".

Imagine how crazy if I tell you a language can't do `[[1,2], [1, b10000]]` and to get into `b10000[:1] where ...` is necessary to switch to another paradigm.

P.D: note how "2 identical values can't exist" break when you have 2 columns, of numerical values, where the slice of both are the same value pair-wise: Are the 2 columns wrong?. And if both are called the same? same type? from different or same table? etc. "Duplicated" values are everywhere and is trivial to get there.

And if you "add a column" then it breaks the soundness of the language:

    IN: [1, 1] != OUT: [1: 1, 2: 1]