Overall I mean the separation of concerns/functionalities into their own compartments, so that they do their thing internally (in an ideal case, of course). As you know, in this way interactions between modules that can lead to all sorts of unpredicted behaviors are vastly reduced. As far as I understood, you were describing debugging a situation where one concern (RC costs) was being influenced and was influencing other concerns, in various subtle loops. The logic of such interactions gets very complicated and can be extremely hard to debug, and obviously leads to fragility where you make a change somewhere and completely unexpected changes pop up somewhere else.
Would it make a difference if the RC code does its thing internally and returns back its results to the main program? I don't know how feasible that would be either. But simple straightforward logic seems far better than subtle and complicated. Obviously refactoring involves a kind of reconceptualization where numerous little things are organized into robust concepts with clear flow of information.
No no, this one is "all stays within family" type of case. RC code was moved from one place to another and cleaned up. The key point is that if you look at the changes, it "is obvious" they should not influence anything, yet they unexpectedly do. It shows that changing blockchain code is a bit like walking on a minefield. It is also an introduction to the power of new RC stamps mechanism that right after its inception caught such subtle influence that would otherwise most likely never be detected.
I have similar story about ongoing bug with power down (its fix will activate with HF28), or already fixed in
v1.27.5, but with wild workaround, problem of strange values on some accounts' properties detected during testing of Balance Tracker app. I might describe them in future articles, since it could be useful case study for people wanting to try their skills on consensus code.