Since 3.12, sys.setrecursionlimit does not control the recursion limit of the C stack (it's hardcoded in Py_C_RECURSION_LIMIT, due to #91079), while the 3.13 docs say

Set the maximum depth of the Python interpreter stack to limit. 
This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python.

The fallout can be seen in #112215 (basically, any code that uses lru_cache in combination with sys.setrecursionlimit is potentially, or actually, broken in 3.12, while still working in 3.11) or in #107263 (which was papered over with an increase of Py_C_RECURSION_LIMIT, not really fixed).

This is an obvious change of behaviour, as code working in 3.11 can easily be broken in 3.12, as found in #112215

import sys
sys.setrecursionlimit(1001)
from functools import cache
@cache
def fib(n):
    if n<1: return 0
    if n==1: return 1
    return fib(n-1) + fib(n-2)

print(fib(500))

$ python3.11 <fib.py 
139423224561697880139724382870407283950070256587697307264108962948325571622863290691557658876222521294125
$ python3.12 <fib.py 
Traceback (most recent call last):
  File "<stdin>", line 15, in <module>
  File "<stdin>", line 13, in fib
  File "<stdin>", line 13, in fib
  File "<stdin>", line 13, in fib
  [Previous line repeated 496 more times]
RecursionError: maximum recursion depth exceeded

Such changes should carry a warning in the documentation.

Potentially, any recursive Python code combining C recursion (in a module, e.g. lru_cache, via @lru_cache decorator) with increased (beyond the hardcoded Py_C_RECURSION_LIMIT) sys.setrecursionlimit is bound to be broken in 3.12.

I believe the whole hardcoding of Py_C_RECURSION_LIMIT has to be fixed (perhaps with a separate API provided to change it), as it's a regression and an incompatible change of code behaviour, but meanwhile the docs have to reflect the reality.