I think we’re maybe at cross purposes about rows / cols?
entrymatcher seems not to support varying the size of entries (and their labels). The number of columns is set when the object is created, and sending names with the wrong size list gets you an error. I don’t see how what you describe can be done, unless you mean adding a new entry…
Again, the things that don’t matter for dict / coll are the labels for entire entries. Neither has a concept of labels for individual indices within an entry.
fluid.dataset~ is exactly the same in this regard. You can insert / delete whatever you want, the relationship between individual rows ( = points = entries) is maintained. buffers, meanwhile, are abstractions that represent a single row/point/entry; just like a list (which also has no label indexing).
What we’ve been dealing with in the last few posts are labels for the individual indices of a point in fluid.datasetquery. I’m not completely clear on how the scheme suggested above does less than the equivalent labelling in entrymatcher.
Maybe what’s confusing is that entrymatcher encapsulates stuff that is spread across different objects for us: it fulfils aspects of fluid.dataset~ (entries of uniform width, recallable by label), fluid.datasetquery~ (filtering entries by criteria against individual columns) and fluid.kdtree~ (recalling sets of entries based on distance).