In the days before heavy security it was quite possible for programs to monkey around with other programs' UI in all sorts of way. A lot of that is still possible from an administrator or SYSTEM-privileged context. Some 15 years ago I wrote an Internet Explorer addon that added stuff to the statusbar by hooking into the IE window's message pump and intercepting winforms calls. Shit was wild.

Growing up in the 90s, I remember an article in Visual Basic Programmer's Journal teaching subclassing in VB by hooking into Notepad and adding a font picker (via a new menu entry that opens the font dialog) to change the text control's typeface. (This was long before MS added that same feature)

Yes, Windows is a kind of OOP based OS at its "kernel" (not to mix with OS kernel).

So one way to extend UI components, since its inception, is to request the Windowsclass structure of an existing control, replace its event handler function and then call the "base class" handler for the built in behavior.

Look at Autohotkey for a starter down the rabbit hole of "we don't need APIs, we have a GUI!" and the fallout of people desperately working around it.

The good old days with AHK. I remember writing the winsock wrapper library and httpquery wrapper back then, software of which i hope has been long superseeded by now.

AHK was how I started programming, good times. When I switched to Linux, this was the main thing that I missed (and I still kind of do on MacOS)

A typical scenario is saving as jpg, where you really want to provide the user the option to select compression level.

That typically is for a single program, though, and by that program. System-wide changes, for example for a product that can compress files on the fly, affect every program using open dialogs.

You say that, but that's standard operating procedure for plugins on web pages.

A node you create could be arbitrarily changed or removed.