> I'm going to echo the previous comment that maybe trying to emulate the existing dict implementation too carefully just adds complexity.

The whole dance with _odict_get_index and _odict_resize is due to the
requirement that OrderedDict maintain O(1) operation for deletion
operations.  Due to using a linked list, we needed a secondary
mechanism for efficiently indexing into the list.  There is a note at
the top of the file explaining the alternatives I considered and the
rationale for mirroring dict's hash table.

>
> The split-keys implementation shows that there is at least some flexibility to the implementation.  Enough that the keys could map to an array offset, rather than directly to the values?

What do you mean by this?  If you are suggesting changes to dict or
its accessory types then it is something I considered and rejected.
Personally I don't want to change anything on dict itself for the sake
of OrderedDict.  If others would like to pursue that they're welcome
to do so. :)