I think that's still a little too restrictive. Sometimes you really do want multiple groups of windows that may belong to the same (think multiple browser windows each with multiple tabs) or different applications (e.g. grouped by task). It's not hard to see how the application marketplace leads to every app doing everything including managing all the things it does, but it's not good for the user.

That is because you are used to shitty window managers / desktop that don't remember position, do not support pinning and tagging windows, etc.

That is the issue, apps have to deal with the lowest common denominator in term of desktop management but there is absolutely no good reason to build a window manager inside a website.I think that with tabs people have generally forgotten they can open multiple browser windows.

As a long time Gimp user, I remember dealing with the same thing but they did eventually fix that. It actually runs in a single window by default now.

Im not sure gimp being constrained to a single window would constitute a multi-document interface.

I mean, old photoshop versions (CS3?) also used multiple windows, so if I were to take a guess that’s where Gimp got it from.

The ‘application context’ isn't a concept that adds value, at least for the applications I've seen. For things where the application windows do need to be treated differently (e.g. patch bays that can be connected together, or widgets that can be fused into larger widgets [1]) I have more sympathy for applications that want to do their own window management. But for something like the browser just grouping Web pages together, that's something entirely unrelated to the browser functionality that should be available in the window manager.

[1]: https://wiki.haskell.org/Eros

What about Cocoa?

I tend to run my tmux session for months at a time on my office workstation. When I remote in to that computer, I can type ‘tmux attach’ and all my context is there. I might have four long arc dev projects running at once, and my planning system, all within those windows.

On our datacentre servers, I also have tmux running. It is fast to connect to these hosts, attach tmux and continue from where I left off.

Another use case: it is common for corporates to require devs to use windows desktops, but to then give them a headless linux host in a datacentre for development work. Here, you use putty to connect to the linux host, fullscreen it, run tmux. On your desktop you have outlook and office and putty and a browser and no dev tools. You can do all your planning and dev work on the linux host, using your favourite ten thousand hours text editor and building your own tools, and this becomes your hub. You lose awareness that you are connected to this from a locked down windows host. Corporate security reboots your windows host for patching several nights in a row, and it does not cause you any hassle because your work context is in the tmux session on another host.

The difference is that tmux, with all its state, typically runs on a remote system. The graphical equivalent would be a VNC &c. session, assuming that the remote machine has the prerequisites for that (which is a pretty big ask).

tmux (and screen) are incredible assets for remote sessions, both for continuity across dropped shells and multi-shell activities when the connection process is tedious (multiple jumphosts, proxies, etc.)

because the OS window manager isn't superior. i have two dozen tmux windows in half a dozen sessions locally. i have shortcut keys to switch between sessions and between windows. i can do that while mixing the terminal with other gui apps. i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.

I would typically not bother with tmux unless ssh is involved.

Abstracting something away and duplicating it for yourself are two very different things! Remember Java Swing?

But I take your point, if you want to target the lowest common denominator of window managers it makes some sense to do your own window management. Mind you you could just ship both a browser and a window manager…

I wonder to what extent the pattern of applications doing their own window management masks (and therefore perpetuates) the problem of inadequate window managers.

The tabs reuse resources of the browser, and the browser does it really well - I think it's not even arguable that browsers are more complex than the OS GUI API, this is why e.g. Windows 11 uses react.js in start menu.

So if you create a webpage that is so damn advanced that it beats the browsers OR it somehow reuses heavy resources within one webpage, I'd say this is a good justification. And IMO the OP link isn't an example of that.

One could argue that this affordance should be provided by the OS for a unified experience.

Even better, WMs can (and sometimes do) support tabs!