It was poorly worded, if that is how it came across.
Probably most so, in fact. I would suspect if anything it would be a bit easier in the Windows version, but I wouldn’t wish to speculate—these things are often spiral into dramatically more complicated problems than you might think, unless the framework or data model has a native way of doing it.
On the Mac, this question was answered in another thread.
None of these examples you list are like Scrivener, though.
Most browsers are not Mac software, outside of a thin interaction layer that acts as a container to the real software (same goes for Electron-ware, like Visual Studio Code and Obsidian)—or that which we would consider the functional part dealing with data inside the window border frame itself—I would tentatively even say the same of Safari, which does have more native Mac UI, but is still fundamentally using a rendering kit in a window. That aside, there is very little beyond superficial overlap between a system that can load data from a remote server and display it in a read-only fashion in a window more than once, and a system that is interactive with your disk storage on a single read/write access point.
The other two examples are not document editors like Scrivener is. Database-based software is inherently capable of overcoming the file system issues mentioned prior, as databases are designed from the ground up to host thousands of concurrent clients all making changes at once—like how this forum works. It’s a popular model to use, for many reasons, but it isn’t without its own downsides as well.
In short, if we don’t allow you to open the same project twice from two different systems (say using file sharing or a local file server) without dire warnings of catastrophic data loss and such—how is that fundamentally different from two or more different instances of the software operating on the same data, simultaneously unless you are using a system or framework built for that capacity from the start?
There are different systems that make this more or less possible without huge performance costs or an imposition on the user, but we aren’t using that technology. One way of doing that is having a plural windowing model all routing through the same singular data document-based model. Mac doesn’t do that out of the box.
It is possible to overcome the natural limitations of the file system issue with a traditional file system and plural document + window model (i.e. multiple agents interacting with one data source without any interaction between each other), but it is a comparably expensive to do so, as it requires all instances to be polling the disk for changes to the files it has open. Now, in a program like Sublime Text where one might have at most a dozen files open at once, that’s can be an acceptable use of resources—and in a program like that you can optimise the process by polling on window activation too, rather than constantly, and alerting the user if conflicting edits have been found and asking how they would like to proceed. I have one program that opts for the active polling route, and even with one document open, it is sitting in the background chewing up a constant 5% CPU, no matter what.
But in Scrivener, where hundreds of files might be actively open? Neither semi-active polling and conflict resolution nor active polling are feasible.
We might as well spend our time on making the project window better. I think it would be a lot more interesting to discuss why you find the existing navigation and splitting mechanisms in the window inadequate, and what you feel we could do better. That is something more within our power—most of the above is the kind of stuff that would take one programmer many years to change.
A lot of thought has been put into making the one window super efficient, but it is one of those things that comes with a level of adaptation and discovery, perhaps it already does things you haven’t come across yet? I will say, for myself anyway, that I work across many dozens of items, cross-referenced between many pieces of research, all with splits, copyholders, bookmarks, keyboard shortcuts and history—and I’ve honestly never really felt like I needed another project window. More active text views? Absolutely—but I’ve got that with QR windows already—and those give me inspectors too, which can solve problems that are hard to get around otherwise with one single inspector.