Es hat nichts mit der Registry zu tun, richtig.
Es liegt leider an der Architektur von Windows. Windows ist seit Windows Vista in zig kleine Pakete zerlegt (siehe %windir%\winsxs). Von einem Paket können mehrere Versionen vorliegen. Es kann aber immer nur eine Version aktiv sein (das sind die Dateien die man dann in system32 usw. sieht -- das sind NTFS Hardlinks). Das Problem ist jetzt, dass es Abhängigkeiten gibt, da manchmal bei Updates neue Funktionen hinzukommen oder Funktionsparameter geändert werden. D.h. eine abhängige Komponente muss dann in einer Version vorliegen, welche mit der geänderten Abhängigkeit harmoniert usw. Gleichzeitig soll auch noch sichergestellt werden, dass die Integrität der Systemdateien gewahrt ist.
Jeder hier wird das Problem kennen: Installierte man Windows 7 zuletzt neu (vor dem SP2 was nicht SP2 genannt werden darf) brauchte es 200+ Updates. Man sollte tunlichst vermeiden 200+ Updates am Stück zu installieren. Nach ca. 50 Pending Updates war der TrustedInstaller fertig mit sich selber.... weil bei jedem neuen Update der Ist-Zustand + alle geplanten Änderungen erneut validiert werden mussten.
Das Problem existiert nach wie vor.
Durch diese Combo-Updates muss jetzt zumindest nur noch 1x geprüft werden...
Naja, und wenn neu gestartet wird kommt dann eben die eigentlich Arbeit: Die Links müssen aufgehoben und neu gesetzt werden (inkl. erneuter Abhängigkeitsprüfung). Außerdem soll das bitte auch Rollback-fähig sein...
Unter Linux als auch MacOS läuft es anders. Letzteres macht Systemupdates zwar auch im Zuge eines Neustarts, hier müssen aber wirklich nur Dateien kopiert werden (ein Grund weswegen es bei nicht-Combo Updates manchmal zu Fehlern kommt: Es fehlen dann möglicherweise Abhängigkeiten, weswegen Mac-Experten dazu raten immer das komplette Update anzuwenden).
https://blogs.technet.microsoft.com...008-and-windows-vista-and-why-is-it-so-large/
Ein ähnliches Problem gibt es auch bei MSI-basierten Installationen. Prominentes Beispiel ist hier Visual Studio. Der ein oder andere wird sich noch daran erinnern, dass SPs hier 2+ Stunden gedauert haben während VS selbst in <20min installiert wurde. Siehe dazu
https://blogs.msdn.microsoft.com/he...or-longer-to-install-than-the-target-product/