The problem with X windows is that it does not present a unified user interface to the user. One program can utilize the Motif libraries, another the athena widgets. This is a major obstacle to commercial acceptance of Unix for companies. If a company cannot be assured that it's application is going to work on every machine, and have the same look and feel, they don't usually want to develop on that platform.
One of the major aspects as to why Windows 95 is such a big success, is that the interface is consistent from one object to the next. The control panel looks and works the same as a directory browser.
Unix needs an environment that can enforce a consistent interface among all objects in the system. This does not mean that every computer has to look like a plain vanilla Windows 95 machine, but all elements in a running system should be consistent.
The only way to allow custom themes (very neccessary) and modularity at the same time, is to adhere to a specific interface between modules. This is where the power of WHY will be realized...the ability to create an OS/2 motif, Windows 95 motif, OLWM motif, Motif motif :), Nextstep motif, and, if we're lucky, some very talented individuals out there could develop some original and snazzy motifs.
The secret to allowing the user interface to exist in the display server without requiring a compile time binding, is in the architecture of the UI objects. Each UI object has a number of events that it responds to. Take a list box for instance:
Event handling
When you scroll a list box, does the program REALLY need to handle that, or could you make the object smart? The WHY design is to make objects smart by default. For 90% of the applications you write, you don't need to know that the contents of the text field changed, or that the list box scrolled, you just need the the state of the objects at the point in time at which the user clicked a button.
Don't misunderstand, you can override the default action of methods for objects. Eventually there should be a server side bytecode interpreter that would allow you to write the event handlers in an intermediate language and upload the "applets" to the server and allow the display server to manage the object entirely without communication with the client program.
This design will significantly speed up interactive performance, reduce memory usage, and make programming the interface a lot easier.