E.g. you figure it'll take a minute to take the trash out and wash your hands. But on the way you discover you run out of trash bags, and while washing your hands you run out of soap, then as you pick the refill bottle from storage some light items fall out, and you need to put them back into a stable configuration, then you spilled a bit of soap during refilling so you need to clean up, but you just run out of paper towels, and...
Letting go is probably most people's answer - nothing bad will happen if I do all the dependent tasks (cleanup, restocking things that just run out) later in the day - but I have difficulty getting them out of my head, they keep distracting me until they're completed.
The cases where the answer is negative correspond to a 'runaway scenario' where every change is expected to cause more than 1 extra change. So the answer is 'nonsensical' (because that is indeed where the formula for geometric series no longer works) but the true answer is infinity.
Each time you set about to make a single change ask what is the probability (p) that this change results in another change, or track this probability empirically, then compute 1/(1-p) this will tell you how much change you should "expect" to make to realize your desired improvement. If you have n interacting modules compute 1/(1-np). This will quantify whether or not to embark on the refactor. (The values computed are the sum of the geometric series in the probability which represents the expectation value)
So this is about how we manage change in a complex system in order to align its functionality with a changing environment. I suggest that we can do so by considering the smallest, seemingly innocuous change that you could make and how that change propagates through to the end product.
In the end, a solution may be to make systems that are easy and painless to change, then you can change them often for the better without the long tail effects that drag you down.