> Hmm, while 2x faster temporal empty dict is nice, 
> 10% slower case can be mitigated.
> I will try more micro benchmarks and optimizations.

I hate to see you working so hard to make this work.  IMO, the effort is futile.  Dicts were intentionally designed to do a single memory allocation and memset(0) to be fully ready to store data.  This PR is undoing that decision and will make Python worse rather than better.  The PR is optimizing for the wrong thing.  The space used by empty dicts is something we care much less about than the cost of the first assignment.

No "mitigations" are going to help.  If there is a second malloc and we incur the cost of switching from sharing-to-non-sharing, that is additional work that will have be done by every single dictionary that actually gets used.  Nothing will get that lost work back.

FWIW, if we were going to optimize for space used by empty dicts, the table pointer could just be set to NULL.  That would be better than key sharing which is not only slower but also conceptually wrong (outside the context of instance creation, dicts will never be shared).

> For the record, legitimate case when many empty dicts are 
> created, and few are populated, is the collections-free 
> approach to defaultdict(dict):

While it is helpful to know that there is some possible application that would benefit, we don't optimize for the rare case, we optimize for the common case where dicts get used.  A substantial fraction of the language is implemented using dicts. For the most part, we use NULL values when the dict isn't actually needed; so, the normal case is that dicts do get used.