When the same document is opened in multiple windows, the editing and syncing experience between drafts becomes complex. If we want to support this behavior properly, we need to improve several parts of the system. Otherwise, the user experience can become confusing and unreliable.

One possible direction is to avoid the model where every document version can be opened repeatedly in new windows. Instead, the app could treat each window as tied to a specific version or draft:

One version = one window

One draft = one window

In this model, if the user tries to open a version or draft that is already open, the app should focus or zoom into the existing window instead of opening a new one.

The main usability problem today is that every time the same resource is opened, a new window appears. Users can easily end up with several windows showing the same document without realizing it, simply because they forget it is already open somewhere else.

However, this model has an open design and technical questions:

Would this limit future editing from embeds?

What happens when navigating between versions inside a window?

If version 2 is open in one window and version 3 is open in another, should navigating to version 2 from the second window be canceled and the first window focused?

Do we still want to support parallel pages?

Should comments follow the same rule?

Is it simpler to update all open instances reactively instead?

There was an earlier experiment with reactive events from the backend that may have solved part of this problem, but that work was paused and not revisited.

The core product question is whether the app should allow multiple live windows for the same document/resource, or enforce a clearer window-ownership model around versions and drafts.

From a UX perspective, preventing accidental duplicate windows seems important. But before deciding, we need to evaluate the implications for version navigation, embeds, comments, parallel pages, and reactive syncing.