Of course. I suppose I should have been explicit to mention things are "system/data-structure ordered" not "key ordered". Any iteration has "an" order, though. That weird order just may or may not be what is desired or it might be fine.
In terms of your `sorta`/B-Tree I would say that (like most fledgling ordered tree implementations) it does not separate "seeking" from "updating" (inserting/deleting). Search trees are often even more useful when augmented. Augmented search trees allow multiple kinds of (useful) order. E.g., B-trees need merely one more number per already large node and a little extra maintenance of that number to support seek-by-rank as well as seek-by-key (thus morphing into an order statistics tree). So, a better design is one organized around a "path handle", e.g., `path: seq[tuple[ptr,index]]`. Seek-by-X procs can populate said `path`, updating procs can act upon it, and iterators can start from whatever kind of seek with next/prev updating some path handle. Done right the augmentation can be totally optional, decided at instantiation-time. Layering a more traditional `Table`-like interfaces on top of that path-oriented internal design is then much easier than trying to implement everything directly.
