Well it's not that I mind PRs that change our tables implementation for the better, but we do have to maintain compatibility and people usually depend on even little details like iteration order (if only in the unit tests) or the fact that tables are `const`-able (something I regret btw). Now we can also add `std / tables2` for a better implementation with a better API but in the end we don't really know the benefits/costs tradeoff.
In the end, a goal like "the stdlib must offer the fastest hash table solution for all the unkown workloads out there" is not realistic. Here is a better goal: "Every table keeps the insertion order so that the split into Table and OrderedTable is gone. Keeping insertion order costs 1% of performance sometimes but cuts the API surface into half and makes Nim easier to use."
