Sounds innocuous indeed and I always found that queued connection weird... I mean resetting to false whatever happens during load? That's fine for simple cases but not real complex ones.

Still, can we have some more extensive testing on a good chunk of the modules in systemsettings? We also have very weird beasts in the mix (KScreenLocker KCM comes into mind for instance but there are more), I'd rather not see them break. It's also worth checking in things like Kontact, KMail and friends which extensively use KCModules for their config dialogs.

I found out why this was added. 7e4b9688d52f55828ba4a5b82e9d8fe5b1a5ff94

In 2008 things changed to being loaded in the showEvent

Many people blindly connecting to widgets changing in the constructor so when we call the deferred load() they're going to change.

This led to some KCMs signalling they changed prematurely so random hacks were "strategically placed" (sic)

I'm still very positive this is technically right.
Whether it'll cause any breakages is another story. For system settings it is a problem if they signal they are changed when they are not as we get an annoying "there are unsaved changes" prompt.

Yes, we really need a large clean up in this area, we got strata of old cruft layered on top often with duplicated states between them. We also have the widget and QML cases being very different in their state management (one comparing widget content with the settings object every time, the other one looking at the state of the settings object). This screams for being properly rethought. With KF6 around the corner it makes it very tempting to revisit.