At a macro level, that cycle was repeated many times, leading to the opposite end result:  a lot of tiny movement/refactor/movement/refactor producing the review and patch annoyances described.

It produces a blizzard of new files and new data structures, breaking a bunch of out-of-tree patches, complicating review quite a bit.  If the vast majority of code movement is up front, followed by algebraic simplifications, followed by data structure work, further patches are easy to review/apply with less impact on unrelated code.

The flow of patches into the tree over time should be examined.  Simply tagging patches as movement-only does not address the described problem at all.