Sorry, I disagree that this is a mere implementation detail. The term "implementation detail" normally implies behaviour which occurs *by accident* due to the specific implementation, rather than being intentionally chosen.

A good example is early versions of list.sort(), which was stable for small lists only because the implementation happened to use insertion sort for small lists. Insertion sort wasn't chosen because it was stable; had the implementation changed to another sort, the behaviour would have changed. (Later on, the implementation did change, and stability became a documented and guaranteed feature.)

This is not what is happening here. The behaviour of for negative count doesn't "just happen by accident" due to other, unrelated, choices. It happens because the code intentionally tests for a negative count and replaces it with the maximum value possible:

    if (maxcount < 0)
        maxcount = PY_SSIZE_T_MAX;


and it is documented in the C source code as a comment to argument clinic:

    count: Py_ssize_t = -1
        Maximum number of occurrences to replace.
        -1 (the default value) means replace all occurrences.


https://github.com/python/cpython/blob/43682f1e39a3c61f0e8a638b887bcdcbfef766c5/Objects/unicodeobject.c#L12682


Some more evidence that this is intentional behaviour: in test_string.py, there are various tests that -1 behaves the same as sys.maxsize, e.g.:

        EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", -1)
        EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", sys.maxsize)


That's not an isolated test, there are many of them.