Do you have a link for the rationale behind this?
So it is not a hashmap anymore? Or in addition to the hashmap, it stores the insertion index? I wonder if it is a good idea to have this part of the language spec, as they might want to use a faster (non-deterministic) implementation later at some point, which would then break again lots of code.
The point of putting it in the language spec is to promise that they won't change back, even if they do later dream up a faster nondeterministic implementation.
The rationale is that even if they clearly said "we might make this non-sorted again later", in practice too much code would end up relying on the new behaviour (whether by accident or because people didn't pay attention to the warning).
So if changing the behaviour is likely to become impractical anyway, they might as well make it a promise so people can benefit from the guarantee.
They made essentially the same choice when they changed sort() to an algorithm that happened to be stable, about 15 years ago.
It's still a hashmap. The idea is to essentially use a separate array for the values and only map hashes to indices into that array. That way your hashmap-part of the data structure is far more compact, so you can use lower load factors without increasing memory consumption too much, which often makes lookups faster (because fewer collisions happen at lower load factors, because the same number of keys is spread over more slots).
That was the reason why they didn't make it a language feature in 3.6. However, after some careful consideration (there are some smart people making these optimizations and language spec choices, I trust they are doing the right thing), they decided to have 3.7 guarantee ordering.
After you have used it for a while, it is a great feature. I would now be happy to take a small dict performance hit in order to preserve the ordering guarantee.
