It would be nice to have a more complete design. What is the problem this change is solving? What does this mean on user level? What new usecases and workflows becomes possible? Why those were not possible before? How's the ID linking and such going to work? Hows does this integrate into the rendering pipeline.

Hey @Sergey Sharybin (sergey) :)

First, I am planning on writing a more complete design on this. I just uploaded the patch to have it out there for people to look at.
There was already a bit of a discussion some time ago in this thread: https://devtalk.blender.org/t/suggestion-make-the-sequencer-contents-into-data-block-which-can-override-the-switched-to-scene-sequencer-contents/16562.

I would say the biggest benefit in removing this dependency of the scene is that you can work with your scene strips while also editing the scenes themselves. No need to switch between an "edit" scene and the scene you are working on. This opens up many powerful layout workflows.

Regarding rendering pipeline: My idea right now is that the user has the option of choosing between rendering a scene (+ compositing) or rendering the video edit (+ compositing). There would no longer be the "Sequencer" toggle in the scene render settings. I know that this is probably very controversial. But I hope that we can all agree that it would be nice to logically separate the two (scenes and the vse). Especially since there is always this awkward cyclic dependency with scene strips that could reference themselves.

Ok, i see. For such projects we really need to have an agreed-on design first. It is a huge change, on both of user level design and technical aspects like render pipeline. While the devtalk might be a place to quickly gain feedback from people, this is not where the designs gets signed off. The design we need to have on the developer platforms.

For the ability of working on an edit and being able to edit scenes themselves I am not sure really sure we need to go into such complexity. This is something you can achieve by pinning scene to a workspace.

For the logical separation: well, maybe. Surely the current situation is unideal, but something still needs to reference the Edit and is not very obvious that the overall workflow will be more clear after such separation.
Currently I am on a skeptic side. To me it seems to be quite a huge project, which benefits are not very convincing. It feels that if we have this energy to be spent we can do much more impactful changes in the VSE. Or, spent time on a design and make it more clear that the benefits do worth the effort.

I totally agree, this needs a good design. The patch is more of a proof-of-concept for me to see what the issues are etc.

This is something you can achieve by pinning scene to a workspace.

Not sure I understand. Since there can only be one workspace visible at a time, this doesn't really solve the problem. People have done this before with two blender windows, one with the "edit" scene and the vse, one with the scene that they want to work on.
But this is all just workarounds in the end.

I do support this idea, but I would agree that there may be simpler solutions to raised issues.
For scene workflow, I too imagined, that pinning would be enough as it allows for relatively quick switching between VSE edit and 2D/3D scene. If such concept is not powerful enough, perhaps it would be good to make some changes there.
But more importantly I wanted to address VSE-compositor pipeline. While I can imagine case where compositor output is used in sequencer, not sure if using sequencer output in compositor makes much sense. AFAIK devtalk thread was about having VSE -> compositor -> VSE pipeline capability to extend image processing capability. For this it would be much better to have node system in sequencer. Now there is also oportunity to reuse realtime compositor stuff which very fast. It would require to rewrite good portion of VSE rendering code, but I would guesstimate it's project of similar size as this one.

I don't want to discourage you, just wanted to share what I would go for personally.

Hey @Richard Antalik (ISS) :) Thanks for your feedback.

I am hoping that such a refactor could open doors for project like this. It's just a hunch but I would guess that future work on the vse could become easier, when it's a bit more independent. We will have to see. I am going to try and get this proof-of-concept a bit further so I can make a better proposal.