Getting two errors with the overlap patch:

Build FAILED.
C:\blender\blender-git\source\blender\blenloader\intern\versioning_300.c(204,3): error C2065: 'bmain': undeclared identifier [C:\blender\build_windows_Full_x64_vc16_Release\source\blender\blenloader\bf_blenloader.vcxproj]
C:\blender\blender-git\source\blender\blenloader\intern\versioning_300.c(204,3): error C2223: left of '->scenes' must point to struct/union [C:\blender\build_windows_Full_x64_vc16_Release\source\blender\blenloader\bf_blenloader.vcxproj]
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:05:44.16

Besides this, it is working really well. 🙂

Maybe consider using the word "Insert" instead of "Expand", since this is an industry term, and this function should insert the strip when drag and dropping it inside another strip, meaning it'll make a split at the in point and ripple push all following strips to the right(but I know that this isn't the main focus right now).

It's a great addition to the VSE! Although, I agree with Peter. It should be optional. A toggle on the interface is great. It could be activated also with a modifier key when dragging the strip over another.

You properly have them on your to do list.

When using the time panel:

When adding a strip & adjust last:

Drag and drop:

The same problems applies to using Extend too.

I have SEQ_iterator.h:38:20: error: declaration of ‘iter’ shadows a previous local [-Werror=shadow] warning escalated to error around transform_convert_sequencer.c:534. Think typical approach of solving this is to append a line number in the macro. You'd need an extra level of indirection, something like:

#define SEQ_ITERATOR_FOREACH_IMPL(var, collection, suffix)
  for (SeqIterator iter ## suffix = {{{NULL}}}; \
       SEQ_iterator_ensure(collection, &iter ## suffix, &var) && var != NULL; \
       var = SEQ_iterator_yield(&iter ## suffix))

#define SEQ_ITERATOR_FOREACH(var, collection) SEQ_ITERATOR_FOREACH_IMPL(var, collection, __LINE__)

Generally fine, but not sure what/where is the best fit for the transform code. Germano will know better.
From me just some strict flags/formatting.

In D11805#311891, @Germano Cavalcante (mano-wii) wrote:

I just fear that creating so many SeqCollections during the transformation can become a heavy operation.
(But if we compare with other datablocks the computation here is minimal).

Not sure if that is valid concern in this case. If you look at transformed_strips here, the collection is created once and then passed where it is needed. Before you would have to iterate whole ListBase with strips, and check which are selected, which is arguably slower but also not quite precise (effects don't have to be selected to be moved).

But you could argue that iterating SeqCollection can be slower when its length is small, but then it doesn't matter. Still this would be good to measure in practice.

There was no reaction to this post above: https://developer.blender.org/D11805#308170
When the function is always exposed in the header, users will expect it to apply in all operations(and not just during Transform).
Same thing with Snapping and Extend(Insert). How are they working during similar operations?
Should I make an additional (bug-)report on this?

In D11805#315322, @Peter Fog (tintwotin) wrote:

There was no reaction to this post above: https://developer.blender.org/D11805#308170
When the function is always exposed in the header, users will expect it to apply in all operations(and not just during Transform).
Same thing with Snapping and Extend(Insert). How are they working during similar operations?
Should I make an additional (bug-)report on this?

Thanks for the feedback on this. No need for an additional report.
I also understand the suggestion about having a "ripple" insert as well, and will take that into account in the next design iteration.

In D11805#315327, @Francesco Siddi (fsiddi) wrote:

I also understand the suggestion about having a "ripple" insert as well, and will take that into account in the next design iteration.

Since you mention it yourself, is the main function of Insert(called: Expand) already implemented, it's just a question of giving it proper exposure in the header ex.: D10074
Ricard already had the exposure of Insert implemented as another edit mode in an enum with Overwrite in this patch.
It is working just as well as the Overwrite mode, so why has it been removed again? Was that your decision?

In D11805#315322, @Peter Fog (tintwotin) wrote:

There was no reaction to this post above: https://developer.blender.org/D11805#308170
When the function is always exposed in the header, users will expect it to apply in all operations(and not just during Transform).
Same thing with Snapping and Extend(Insert). How are they working during similar operations?
Should I make an additional (bug-)report on this?

These settings only apply to transform operator.

In D11805#315335, @Peter Fog (tintwotin) wrote:

In D11805#315327, @Francesco Siddi (fsiddi) wrote:

I also understand the suggestion about having a "ripple" insert as well, and will take that into account in the next design iteration.

Since you mention it yourself, is the main function of Insert(called: Expand) already implemented, it's just a question of giving it proper exposure in the header ex.: D10074
Ricard already had the exposure of Insert implemented as another edit mode in an enum with Overwrite in this patch.

Idea was to implement this feature in bit more defined way before adding it as option

! In D11805#315747, @Richard Antalik (ISS) wrote:
These settings only apply to transform operator.

How are the users supposed to know this? When exposing it in the main vse header, there is no reason not to assume, that all operations moving strips/clips or changing durations should be affected by this setting? Should it be moved into the Tool Settings header? And what about snap and extend are they also only for the transform operator? If so, should they also be moved into the Tool Settings header?

[From a user perspective it would make perfectly sense to let these setting affect all strip movement, and not just when the movement is done through the Transform operator]

For the record, I had a chat with Richard about reverting to an earlier version of the patch, where the 3 possible transform modes are are presented through and enum.
In a next version of the patch (or after it's merged) it would be ideal to have some icons instead of the enum. @Pablo Vazquez (pablovazquez) was working on a proposal, also taking into account the suggestion from @Peter Fog (tintwotin).

It seems to fail when several strips are moved:

Limit the red warning outline to Shuffle mode only.

Imo, the Overlay enum doesn't need the text: "Overlap Mode".

Shift+S with a handle selected is also a situation users might expect Overwrite to work(but it isn't handled by the Transform operator):

The "transparent during transform" look is added when strip is placed, and only corrected when transformed again:

In D11805#316332, @Peter Fog (tintwotin) wrote:

It seems to fail when several strips are moved:

Limit the red warning outline to Shuffle mode only.

I think overlapping strip/area should be visible in all modes, but it could be distinguished somehow

Imo, the Overlay enum doesn't need the text: "Overlap Mode".

This will be fixed with icons.

Shift+S with a handle selected is also a situation users might expect Overwrite to work(but it isn't handled by the Transform operator):

I can imagine this mode being used with different modal operator. I guess here it would make sense too, but not sure really.

The "transparent during transform" look is added when strip is placed, and only corrected when transformed again:

Yes, I have noticed

In D11805#316672, @Richard Antalik (ISS) wrote:

In D11805#316332, @Peter Fog (tintwotin) wrote:

It seems to fail when several strips are moved:

Notice that the strips are overlapping after release and not overwritten, as they're supposed to be.

I suggest to remove the "Overlap mode:" label and then this is good to merge.

In D11805#320323, @Francesco Siddi (fsiddi) wrote:

Let's merge this!
I prepared some documentation text, which will be pushed as soon as the code is merged. Suggestions are welcome.

Expand
   All strips will be shifted forward to accommodate the overlapping strip.

It's more "all strips on right side of (each) transformed strip will be shifted forward...", if I remember correctly.

There are some other oddities and exceptions, but then you may copy paste code to documentation.

Great to see this being committed, but just a note on the name of Expand(and on the documentation). In the Strip/Transform menu there is also an Extend function, this is for extending the duration of strips only.
The function now exposed in the Overlap enum is also for moving strips around, where you can insert strips in between other strips. Both inserting material by trimming/transforming strip durations and moving around the order of the strips is referred to as "Insert" as industry standard. So maybe you could consider renaming this function at some point, so it'll fit better with the functionality of it, and improve the UX.

The functionality:

A freeware reference:
Flowblade: https://jliljebl.github.io/flowblade/webhelp/edit_tools.html#Insert