We tested and discussed this quite a bit here at the studio, Hjalti gave some initial feedback too. Francesco, @Sebastian Parborg (zeddb) and I decided that the following should be done for now:

• The auto-scrolling causes a number of usability issues, we shouldn't do it. It basically enforces the limits too much, and moves away too much from the canvas principle. E.g. after removing a lone strip in the uppermost channel, it should just keep the view, and not move to the next highest strip.
• The behavior proposed here should be optional, it can be enabled by default. The option can go to the View dropdown, e.g. View → Limit View to Contents (name is just an idea of course)
• The edge panning should happen earlier, so the expanding of the view becomes more discoverable. A SEQ_EDGE_PAN_INSIDE_PAD of 3.5-4 should be fine, personally I prefer 3.5.

These things need to get done for this to be ready for a release.

Bugs/issues that can be addressed in bcon3:

• According to the scrollbar, you cannot scroll all the way to the bottom.
  
  I think you have to add the bottom offset in the View2D.tot-rect calculations, the cur-rect may still show contents out of tot bounds I think. Or maybe it's more difficult, not sure.
• The view panning doesn't work when you start dragging within the margin of the edge-panning (SEQ_EDGE_PAN_INSIDE_PAD). If this is increased as mentioned above, this becomes a notable issue. However this is intentional for nodes (4d605ef2f413), and managed via the View2DEdgePanData.enabled option. You could make that behavior optional, e.g. with some UI_view2d_edge_pan_set_xxx() option (not sure about the name).
• Sometimes when testing I ended up with a channel 8 visible, without being able to scroll it into view. I don't have clear reproduction steps unfortunately.

Thanks for review, I can do these changes, but following I am not sure if I understand correctly:

In D14263#397024, @Julian Eisel (Severin) wrote:

• The auto-scrolling causes a number of usability issues, we shouldn't do it. It basically enforces the limits too much, and moves away too much from the canvas principle. E.g. after removing a lone strip in the uppermost channel, it should just keep the view, and not move to the next highest strip.

Does that mean that limits would not be enforced, but it is possible to scroll only down? If that is the case and user will scroll down but there is still "free space" left, should this be a new limit, so it is not possible to scroll back up where deleted strip was?

My concern is, that without this auto scrolling, scaling and maybe even panning can feel awkward. I had some issues controlling these things so they feel intuitive. But perhaps with above exception to limiting this wouldn't be an issue.