I think he's referring to the fact that maps are iterated in random order. Now if you print them directly, you may be lead to believe that the order is _not_ random.
If you print them one by one while iterating you would quickly discover the truth. Not sure why this would be worth making the string rendering of large maps much harder to use and compare (eg in log entries). Since any rendering implies an order (which is not guaranteed to remain consistent through the program's lifetime), then any string rendering of a map should be considered misleading by your logic.
Given Python's success with its insertion-order-retaining "compact dict" implementation[1], I've wondered why more languages aren't adopting that design into their maps/hashtables.
"The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon"
Early in Go's development, they intentionally randomized the iteration offset to make sure developers didn't become dependent on a behaviour they didn't want to be tied to.
You see this in Erlang also, where iteration order is deterministic (though not based on insertion order), but documentation makes sure to say iteration is arbitrary.
So, the answer to your question is that most people don't want their dictionaries implementation to be tied down due to this feature.
There's a big difference between "iteration order is deterministic" and "iteration order is <very specific high-level behaviour>" even if the latter is a side-effect of an implementation details. In particular, iteration order being either insertion order or sorted are useful and sought-after properties, while other implementation-dependent deterministic orderings are mostly implicit dependencies and sources of bugs (not unlike e.g. the scheduling sequence of goroutines in Go).
I wonder if this isn't going to be seen as a mistake in the future. What if a faster map is discovered in 3 years that happens to not preserve order? This stuff is really hard to detect, so there's no going back on it.
That was likely weighed and I'm guessing the answer is that they would introduce a new type under collections, but that the new dictionary makes most sense for users while also currently being faster
In Python, they'd probably just make it a separate class, just like `OrderedDict` is/was. People who needed the performance would use it and everyone else would enjoy the convenience of ordering.
