This is a bit weird why it's only done in one place. There are other places from where BKE_sequence_calc is called, and some other places where strip position is changed (RNA properties, Python API, and so on).

In D8340#204052, @Sergey Sharybin (sergey) wrote:

This is a bit weird why it's only done in one place. There are other places from where BKE_sequence_calc is called, and some other places where strip position is changed (RNA properties, Python API, and so on).

This is fix only for transform operator. Following code more closely this is best place I could find to offset animdata. BKE_sequence_calc will look at effect inputs and adjust it's position in time.
I am using this approach here for several reasons:

• I could traverse strips when moving "base strip", but I really don't want to increase problem complexity. This operator is incredibly slow as it is now. Traversing would have to be recursive loop over whole seqbase
  • Some operators already handle this problem by own logic. Doing this effectively inside BKE_sequence_calc may be possible, but it's recipe for disaster. There should be no such function as BKE_sequence_calc
  • from python API point of view, we can change strip position and we don't need to reference seqbase. since strip have no idea if it has any effects, we would have to look in scene, where exactly strip is, then traverse seqbase and offset animdata. It is possible, but unnecessary for this fix IMO
• we don't know what strips exactly are overlapping, we could change this, but I just don't want to do it yet. Current logic is is_effect_overlapping? move_it_up : move_it_sideways_and_possibly_up;

So this left me with solution: Whatever happens, capture previous state of effects, and if they teleport, adjust animdata.

Thing is: such manual animation offsets calls are fragile. One might think of a better API which would do something like "place this strip to time FOO, offset its and all related animation".

In D8340#204304, @Sergey Sharybin (sergey) wrote:

Thing is: such manual animation offsets calls are fragile. One might think of a better API which would do something like "place this strip to time FOO, offset its and all related animation".

I am aware that this is not nice solution. I would rather rewrite this whole thing, but this is supposed to be bugfix.

Why not fix this behavior now when we can?

I don't see a reason why not to start working on a reaosnabel API and gradually spread it over, without rewriting the whole thing. It should be possible and simple to make a tiny new function, which is then to be used in all areas which moves strips.
You can use this function in a single place there in the transform code.