> In the CPython code base, _Py_NewReference() is used:
> * to implement the free list optimization

I found a similar code pattern outside CPython code base.

Like Nuitka generic macros for free lists:
https://github.com/Nuitka/Nuitka/blob/8e2357ee8e9a93d835e98d5a88ca0181cc34dabc/nuitka/build/include/nuitka/freelists.h#L22

Another example in the old unmaintained gmpy project (last release in 2013):
https://github.com/LogicalKnight/gmpy/blob/5d758abc9fcb44b08dd000145afe48160bd802f1/src/gmpy2_cache.c#L93-L111

These functions can opt-in for the internal C API to continue to get access to _Py_NewReference().

Or maybe free lists should be implemented differently? (is it possible?)


> * in _PyBytes_Resize() and unicode_resize() (resize_compact() to be precise)

Third-party code can use the public PyUnicode_Resize() function and the private _PyBytes_Resize() function. Later, if needed, we can consider to expose _PyBytes_Resize() in the limited C API.


> * by PyObject_CallFinalizerFromDealloc() to resurrect an object

I found a few projects which basically reimplement the PEP 442 logic in their tp_dealloc function. Example with pyuv resurrect_object() function:
https://github.com/saghul/pyuv/blob/9d226dd61162a998745681eb87ef34e1a7d8586a/src/handle.c#L9

For these, using PEP 442 tp_finalizer here would avoid relying on private functions like _Py_NewReference(), make the code simpler and more reliable.