I prefer old, orig, or source to ms.
And I prefer "declare and initialize at same time" style because we can use C99 syntax.

I prefer "early return" style without "else" clause.

I meant all local variables can be defined where it's initialized.
for example,

for (Py_ssize_t i = 0; i < keys->dk_nentries; i++) {
    PyDictKeyEntry *entry = &ep0[i];
...

https://google.github.io/styleguide/cppguide.html#Local_Variables

C++ allows you to declare variables anywhere in a function. We encourage you to declare them in as local a scope as possible, and as close to the first use as possible. This makes it easier for the reader to find the declaration and see what type the variable is and what it was initialized to.

C99 is same to C++ in this case.

Done

Are these test changes actually related to the code changes? Or are they just test hardening that you thought of because of the new code? If so, the test improvements should go in regardless of whether or not the code changes do, and ideally as a separate commit.

The one case it slowed down was an empty dict ... is it worth a special path to drop out and just create a new empty dict then?

Added a fast-path for empty dicts.

incref (missing the 'c')

fixed

Am I missing some context, or is this refusing to use the fast path for shared-key dicts, when the fast path would still be good for 2/3 arrays, and the other just replaced by an INCREF?

I don't want to complicate the code for speeding up shared-key dicts copy. Copying a shared dict is a very rare operation.

Any reason not to at least use presized?

This change isn't concerned with updating/touching the slow path.

would you mind to rename the function to "clone_combined_dict()"? It requires ma_values==NULL.

Instead of an absolute number, why not using a ratio? 3 unused is may a lot if the dict contains 16 items, but what is the dict contains 2^16 items?

Would it make sense to use a ratio, tolerate a maximum of 10% unused entries? Or 1%?

What does impact performances of dict.set(): the absolute number or the ratio?

If it's the absolute number, just explain that above, something like: "each unused entry make dict.set() slower, so create a compacted dict for optimal performances".

MALLOC is an an alias, use directly PyObject_Malloc().

dk_refcnt==1 test seems redundant, the inner assertion is enough IMHO.

Extract of dictobject.c:

The DictObject can be in one of two forms.

Either:
  A combined table:
    ma_values == NULL, dk_refcnt == 1.
    Values are stored in the me_value field of the PyDictKeysObject.
Or:
  A split table:
    ma_values != NULL, dk_refcnt >= 1
    Values are stored in the ma_values array.
    Only string (unicode) keys are allowed.
    All dicts sharing same key must have same insertion order.

dk_refcnt can only be != 1 if ma_values is not NULL.