Out of the box macOS doesn't have a button to maximize the way Windows does. The green button in modern macOS is for full-screen and option-clicking that button will bring back the old "zoom" behavior which expands the window to fit the content being displayed. It's a lot less frustrating of an experience when you realize that the button doesn't do what you assume it does.
I suspect that'd play absolute hell with either their UX concept or the underlying UI abstractions / implementations.
This would create a situation where an application has one window foreground above the foreground application while it is not the foreground application.
On the UI / implementation side: I don't think it's possible to have any windows of an app foregrounded past the foreground app's frontmost window if that app isn't itself foreground. They'd have to create a new category of window (and probably move a bunch of internal data structures around) to make that possible. I know, "it's just code," but it's code based on some very deep and old assumptions about the way the window manager works that probably have hard-to-predict consequences if violated.
On the UX side: having a window floating foreground when the top-of-desktop menubar says another app's name in the corner is going to trigger a "WAT" for a lot of users, and I think Apple is deferring to them.
I understand, and even appreciate, that they don't let too much customization on their default programs. But why can't you run a different program? It makes no sense.
Depends on what you mean by "run a different program". You can't really replace WindowServer on macOS, as it is pretty much macOS itself. macOS is not really as modular as Linux or even Windows. There are things that hook into it to give extra behavior (Helium, Afloat, Magnet, Amethyst, chunkwm, several others in the AppStore), but replacing it is not really practical, I believe.
> You can't really replace WindowServer on macOS, as it is pretty much macOS itself.
I find this very foreign. As if a unix system didn't let you change the shell!
This is sad to hear, because I'm a happy user of a headless macOS (not set up by me), to which I ssh almost daily for testing purposes, and it is a fairly decent unix system. It has a few idiosyncrasies, sure, but those help to make your pipelines more portable. I always supposed that the GUI would be just a regular program running on top of that unix.
The window manager is definitely a "default program" that is probably tightly integrated in various points of the OS. AFAIK, you can't even use the OS without having Finder running (not the actual window "Finder" but the process) as it's also involved in lots of things, like the desktop and such.
I believe Finder is not technically necessary, as seen on Apple's installers and restore mode (which are a smaller version of macOS). You can kill it with Force Quit, for example. It is indeed also the provider of the Desktop, but everything else works: Dock, Menubar, Command+Tab.
It is launched via /System/Library/LaunchAgents/com.apple.Finder.plist
No...macOS doesn't work that way. There are a few hacks (Afloat, Helium) but all require disabling SIP, which is not desirable. And even if they didn't require disabling SIP, they only work part of the time in my experience.
Windows does not use a window manager like X does; the frames are drawn and managed by a library used by all applications, it’s not a separate program.
I’m not 100% sure but I’d say it’s pretty likely Mac OS works the same way, just like on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application (using a system library so the application developer doesn’t have to worry about how it works).
> on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application
IIRC it is not drawn by the application, it's a system app that gets the focused (or rather, activated) app menu hierarchy as the app instructs through some IPC, but it's not the app process itself drawing there. The only part where an app actually can draw is on the right part, when one implements menu bar extras (which previously required hacks to inject into because the menubar extra API was severely limited, but IIUC now has a dedicated, managed API to replace the hacks)
I'd already be happy if maximizing a window on macOS worked reliably.