I'll bring this up at the language sprints.  Last year, there was an explicit decision to not go down this path.

Here are a few thoughts for now:  It is a big deal to change the API.  We try hard not to do that (breaking code for no reason and making it more challenging for people to upgrade their python -- the standard library is intended to be standard rather than highly mutable). It is a big deal to rip-out the pure python version and impose obligations on other implementations.  Over time, we've tried to move in the direction of more pure python code rather than less.  The pure python code is easier to understand, easier to maintain, generally less buggy, and is more portable.  People currently using OrderedDict are choosing it specifically because they want the ordering behavior.  That is currently implemented in an algorithmically correct way that preserves the big-oh behavior in the face of deletions and updates.  In contrast, the regular dict only happens to be ordered and internally is achieving order by maintaining a sequence of consecutive pointers.  This doesn't have the same performance characteristics and would be a step backwards for some use cases.  Lastly, if the ordering of regular dicts becomes guaranteed, then collections.OrderedDict() will mostly become irrelevant so there is no need to change it all.

For now, this proposal is on hold because 1) it isn't clear that it should be done, 2) it needs a lot of serious discussion before proceeding, 3) it may be premature while the status of the regular dict is still in flux.