With older Windows version, you got pretty GDI “trails” as you dragged a window around. Now you get blanked out elements.
For some reason, I thought that something like Plan 9 would have been flawlessly written (like their CLI counterparts) and that it would be immune to visual issues like that.
Specifically, applications were issuing drawing commands which were executed directly onto the framebuffer - there was no "draw into rectangle then another process will compose it", because GDI was written for systems that simply didn't have enough memory for that.
Essentially the process looked like this:
1. Windows GUI system figures that a specific window (this could be everything from full application window to individual control) became visible
2. WM_PAINT (iirc) message is sent to the application, to specific window
3. the handler for WM_PAINT of the specific window is triggered (there might have been support for buffering pre-existing draws, too), and executed GDI calls to draw the component (canonically using a state pointer to associated data block with everything necessary for repaint)
4. The GDI system does the drawing directly on the graphic card (either fully in software, or through accelerated calls exposed by driver)
5. Next window that needs painting gets called etc.
This meant that when the applications hanged, or simply didn't have time to process drawing requests fast enough, you ended up with "trails" due to remaining old data in framebuffer.
With WinNT6+ and DWM, GDI applications each draw into their own buffer which is then composited by DWM. This means that at worst they break their own windows' contents, but not the global framebuffer.
This is / was the case for several of the early-generation window managers, including twm, fvwm, and probably a few of the *Step window managers.
I suspect you might be able to pull this off with GNOME or KDE though I've not tried this in some time.
When restarting WindowMaker, the "naked" windows are briefly painted (without decorations) to the display, then decorations (frame, titlebar) reappear and windows resume their status (open/closed) and remain near their positions (the decoration toggle usually means they shift down and rightwards).
Great resources and discussion board here: http://www.nextcomputers.org
Really if you have any NeXT software you should make copies and share with the world.
GNUSTep is an implementation of the Openstep spec, so there's a good chance that that old software could be ported to Linux (or even OSX) without too much effort.