blokhead,
So it boils back down to efficiency. It does NOT resort for every insertion though. That is why I keep saying there are several optimizations that prevent it from resorting until necessary. It works like this:

• When FIRSTKEY is called, it will reorder the hash if the optimization flag is set to none or if the changed flag is on
• The changed flag doesn't get set if the change will not affect the ordering (a value change when the sort routine is only looking at keys)

This means that unless you invoke keys, values, or each between every insertion - there will only be 1 resorting by adding 50 new entries into the hash.

I had considered making changes "smart" but it was not clear to me that it would be more efficient. It all depends on how it is used. If the hash is asked for many times with only a few number of changes in between it makes sense to use "smart" inserts. If on the other hand the hash is asked for only intermittently with potentially many changes it makes sense to use my current approach.

I guess if I make any modifications, which I am currently not inclined to do - I would provide the option of selecting which "mode" to use since the efficiency of either approach depends on usage.

Update: (in response to your update):
they don't actually help asymptotically, unless you perform O(n log n) insert/delete/fetch operations in between every call to keys.

Not exactly. Unless there are changes and those changes effect the order and those changes accumulate to O(n log n).