> > the result is  C -> A -> B -> C

> Did you mean C -> A -> B?

No, I meant C -> A -> B -> C -> A ....
the cycle remains unchanged.

> By the way, if you applied to this example your reasoning that  PyErr_SetObject shouldn't try to fix user bugs, should this example  instead be C -> A -> B -> C -> ... (leaving the cycle as is but just not hanging)? 

Yes, exactly, see above.

> Is it not being changed then because the reasoning doesn't apply, or because we're restricted in what we can do by backwards compatibility?

The reason for leaving the cycle unchanged is not backwards compatibility, it's that this function cannot break the cycle in a meaningful way (this is why it's hard to agree on how it should do that).

It can't be that A happened in the context of B at the same time that B happened in the context of A. So a cycle means there was a bug somewhere, and the exception's history is corrupt, so changing it will only make it more corrupt and harder to debug.

Note that PyErr_SetObject avoids creating cycles, so the cycle was not created by someone catching an exception e and doing "raise e". It was caused by some other code tampering with the __context__ in an incorrect way.