On the other hand, Antoine is correct in that we _could_ use the existing infrastructure and count PyIter_Next() as a recursion in the same way as entering the ceval loop is a recursion.  Extra checking in there would hardly slow down the execution much.  (but it would have to do its job only when invoking a "c" implemented iternext routine...)

I tried to come up with other ways that we could create deeply nested C function calls...
Here's one:
...
    a = (a, a)
    b = (b, b)
a < b

This however gets caught by this code:
    if (Py_EnterRecursiveCall(" in comparison"))
        return NULL;
    res = do_richcompare(v, w, op);
    Py_LeaveRecursiveCall();

So obviously someone thought this could be an issue.

However:
...
     a = {1: a}
repr(a)

will generate the same crash. (tuple repr and list repr have guards, dict repr not)

So, there are various ways to get c recursion to overflow the C stack.  Some of them have been patched throughout the years, others not.

We could try to identify all the different ways.  We could for example add guards in PyObject_Repr() rather than individual types.  But I'm sure we will leave holes in place like the OP discovered with deeply nested iterators.