The stage has been set for applications to hang without affecting system performance. Internally the stage has also been set for multiple applications to process input simultaneously. Much input synchronized state has been made thread specific – except for window z-order (overlapping order). Bringing a window to the top, i.e. changing its z-order, is most often associated with a mouse click or some other user inspired operation, thereby being associated with input.
This is not thread specific state, but is state related to the global state of the window tree internal to the window manager. A user would not want to feed a mouse click to a hung app, only to have that app process that click later and bring itself on top, covering what work the user was currently doing.
So activation related z-order will not change z-order the application relative to other applications. For example, an activation related z-order would bring a dialog on top of its application, but not on top of all applications.
In most cases only the user can change the z-order of applications, and this is done simply to redirect input to the application of choice. In rare cases applications actually want to cause input to switch to a predetermined window and have that window come to the top. These are cases for `hard-error' alert windows, application startup, application shutdown, etc. For these cases a special function will be created, called SetForegroundWindow.