Well, I wrote that stuff in the early-to-mid 90's, but you're right that I'm actually in the camp that advocates being able to totally reconfigure the user interface. I just think there are better ways of doing that than how X works, and X only lets you change the window manager, but not anything else.
The thing is that X's configurability sucks (.XDefaults files, and the various ad-hoc syntaxes of the various window manager configuration files, which may or may not run m4 over them so you have yet another crazy macro syntax layer).
Since the user interface toolkit and window manager in NeWS was defined as PostScript classes loaded into the window server and shared by all applications, you could subclass or patch or redefine them (usually when NeWS was starting up), and as long as they still supported the same APIs (which is a big limiting factor on what you could do of course -- pie menus emulated the linear menu api, but a linear menu api is not necessarily the best api for pie menus), then ALL applications would pick up the changes.
Of course there were some things you could change on the fly (like the default menu class, except that if apps cached instances of menus instead of recreating them, they would not change), but you could not redefine the window frames on the fly since they already were created, and reparenting the clients into new frames wasn't trivial.
There was a function to change the default menu class used by the window manager, and it knew how to create new menus with the new classes based on the old menus, for the root menu, and also the window frame menus. But any applications that created menus would have to be in on that game. It would certainly be possible to make a MenuClassChanged event to tell them to recreate all their menus, but nobody ever bothered to do that, since it wasn't something that people needed very often, and would require a lot of work for application developers.
You have to weigh how much the flexibility costs in terms of complexity and efficiency against how much people really need the flexibility, and at what time they need it (immediately at any time, app startup time, server startup time).
X pays a very heavy price in terms of complexity to be able to support changing the window manager on the fly (or rather, plugging in different window managers, without providing a turing complete extension language in the server). And it's not because they necessarily badly wanted you to be able to change window managers at any time you felt like it without restarting the server (which was nice, but not something users were clamoring for), but it was because they just didn't want to dictate any "policy" about how window managers should work.
And why just the window manager, and not switch the entire user interface toolkit -- you still want to do that don't you? I'd rather have an architecture where all applications share the same user interface toolkit that runs in one address space local to the server, and have a consistent and customizable user interface, which is how NeWS worked. That's much more important to me than being able to change the user interface on the fly, in my opinion. And it has other nice side-effects like it does not suffer from network race conditions or even context switching overhead, and all the ui code lives in one place and is not duplicated, which mattered a lot in the days before SunOS supported shared libraries -- Sun actually linked all the common SunView apps together into one gigantic monolithic app that would behave like a different app depending on the name it was invoked with on the command line, so the SunView user interface libraries were shared in memory and started up faster, by virtue of the fact that all the standard SunView apps WERE the same app (SunOS did at least support multiple instances of the same app sharing read-only code).
The thing is that X's configurability sucks (.XDefaults files, and the various ad-hoc syntaxes of the various window manager configuration files, which may or may not run m4 over them so you have yet another crazy macro syntax layer).
Since the user interface toolkit and window manager in NeWS was defined as PostScript classes loaded into the window server and shared by all applications, you could subclass or patch or redefine them (usually when NeWS was starting up), and as long as they still supported the same APIs (which is a big limiting factor on what you could do of course -- pie menus emulated the linear menu api, but a linear menu api is not necessarily the best api for pie menus), then ALL applications would pick up the changes.
Of course there were some things you could change on the fly (like the default menu class, except that if apps cached instances of menus instead of recreating them, they would not change), but you could not redefine the window frames on the fly since they already were created, and reparenting the clients into new frames wasn't trivial.
There was a function to change the default menu class used by the window manager, and it knew how to create new menus with the new classes based on the old menus, for the root menu, and also the window frame menus. But any applications that created menus would have to be in on that game. It would certainly be possible to make a MenuClassChanged event to tell them to recreate all their menus, but nobody ever bothered to do that, since it wasn't something that people needed very often, and would require a lot of work for application developers.
You have to weigh how much the flexibility costs in terms of complexity and efficiency against how much people really need the flexibility, and at what time they need it (immediately at any time, app startup time, server startup time).
X pays a very heavy price in terms of complexity to be able to support changing the window manager on the fly (or rather, plugging in different window managers, without providing a turing complete extension language in the server). And it's not because they necessarily badly wanted you to be able to change window managers at any time you felt like it without restarting the server (which was nice, but not something users were clamoring for), but it was because they just didn't want to dictate any "policy" about how window managers should work.
And why just the window manager, and not switch the entire user interface toolkit -- you still want to do that don't you? I'd rather have an architecture where all applications share the same user interface toolkit that runs in one address space local to the server, and have a consistent and customizable user interface, which is how NeWS worked. That's much more important to me than being able to change the user interface on the fly, in my opinion. And it has other nice side-effects like it does not suffer from network race conditions or even context switching overhead, and all the ui code lives in one place and is not duplicated, which mattered a lot in the days before SunOS supported shared libraries -- Sun actually linked all the common SunView apps together into one gigantic monolithic app that would behave like a different app depending on the name it was invoked with on the command line, so the SunView user interface libraries were shared in memory and started up faster, by virtue of the fact that all the standard SunView apps WERE the same app (SunOS did at least support multiple instances of the same app sharing read-only code).