Compositing was a hardware change, though. Modern GPU's (including GPU chipsets that are integrated as part of a CPU chip) basically accelerate 2D rendering by managing arbitrary surfaces as glorified sprites, which the hardware can "project" or "render" into other surfaces or on the screen in all sorts of ways, including occlusion, alpha blending, arbitrary 3D transforms etc. Hardware of the Win95 era didn't have anything like this; even moving and resizing windows only "animated" a wireframe rendition of the window, as with twm today.

I do not like compositing though, at least not the way it is implemented in pretty much every current desktop environment (including Windows) where the composition is synced to the monitor refresh rate, meaning that it will always be at least ~8ms late on average and that is assuming everything else is synchronized - but this is not the case as applications draw their output offscreen to a surface that is picked up by the compositor (the mechanism of which is irrelevant, the application might just render to a compositor provided resource or the compositor might copy a VRAM surface or it may transfer bytes from the system RAM, it doesn't matter much in what i'm describing) which happens asynchronously and then notify the compositor that the window contents have changed which is again picked by compositor asynchronously. This introduces several frames of delay between the application drawing something and it appearing on your monitor. It is not a big problem when you are passively watching something, like a movie or an animation, but when that "something" that is drawn is an immediate reaction to an action you just did (like resizing a window with your mouse) you can "feel" that delay.

With non-composited window systems (which nowadays is pretty much only Win7 with DWM disabled and pure X11/Xorg) all that overhead goes away since applications draw directly to the video memory that is to be presented to the monitor (the GPU might do some minor composition itself but that is irrelevant as there aren't any delays involved).

Compositing would work if all composition was done on the GPU using dedicated hardware (similar to how the GPU already performs composition for the mouse cursor and an overlay that is often used for HUD-like controls like volume control, but those are not general purpose features that can be used for desktop composition) and applications could draw directly to the video surfaces that would be composited pretty much the same way a non-composited desktop can draw directly to the video memory (this would introduce artifacts like tearing but this is something that could be handled separately and to some - like me - tearing is perfectly acceptable for pretty much all interactive actions).

I am not aware of any GPU or window system that does compositing like this though.

> Launch-programs-by-search becoming common is the only significant advance I can think of since the 90s.

Windows had this since at least Win 7, so it's not really a recent advance. I dislike that the the Win 10 start menu is essentially unusable enough that it requires actually doing a search, though, which is why I use a replacement start menu.

> Launch-programs-by-search

Which ironically doesn't work well anymore with Windows 10 because the start menu is often too laggy to open, or because it performs any other kind of unwanted search like web search.

The investment is too great in custom Control Panel extensions from hardware vendors, including for hardware supplied to basically all major OEMs. If they toss that, a lot of hardware will become unconfigurable.

Control panel has to stick around for compatibility with legacy apps, including those that register functionality into it and call it's paths directly.

It's pretty well hidden from users at this point and basically just a collection of links to compatibility components. I've never understood the concern.