Es ist unmöglich mit Gewissheit zu sagen, ob "diese Methode in einer zukünftigen Version von Windows verfügbar sein wird". Aber man kann eine bessere Vermutung anstellen, wenn man tatsächlich versteht, was sie bewirkt.
Realistischerweise funktioniert diese Methode, weil sie die Registrierungsinformationen für das File Explorer UI-Komponente zerstört. Dies geschieht, indem man diese Schlüssel zu HKEY_CURRENT_USER hinzufügt, wo sie die entsprechende, korrekte Registrierung in HKEY_LOCAL_MACHINE überschreiben. Wenn versucht wird, diese CLSID zum Erstellen der File Explorer UI-Komponente(n) zu verwenden, schlägt dies fehl, weil der InProcServer32-Schlüssel keinen Wert hat, der standardmäßig auf 'C:\Windows\System32\Windows.UI.FileExplorer.dll' und einen Wert für den Threading-Modus zeigt. Es scheint, dass es als Alternative einfach das Standardmenü anzeigen wird. (Es ist auch möglich, dass ein Fehler genauso auftritt, wie wenn man "Mehr Optionen anzeigen" anklickt, wenn dies ansonsten erfolgreich war?)
Es gibt also viele Gründe, warum es möglicherweise nicht funktioniert, aber die allgemeine Annahme - die Registrierung zu unterbrechen - wird funktionieren, solange das neue Kontextmenü mit dem File Explorer verbunden ist.
Das "alte" Kontextmenü gehört zur Windows Shell, das "neue" Menü hingegen zum File Explorer. Solange sich das nicht ändert, scheint es unwahrscheinlich zu sein, dass es keine Möglichkeit gibt, einfach die entsprechende File Explorer Komponente "auszuschalten". Natürlich könnte es sein, dass der File Explorer aufhört, die alten IContextMenu-Schnittstellen überhaupt zu verwenden, dann könnte es sein, dass das Deaktivieren des "neuen" Kontextmenüs verhindert, dass überhaupt ein Kontextmenü angezeigt wird, aber ich kann mir nicht vorstellen, dass sie so ungeschickt wären.
Übrigens gibt es eine "bessere" (oder zumindest andersartige) Methode, um das neue Menü zu deaktivieren, und zwar die genannte CLSID zur Shell-Erweiterungs-Blockliste hinzuzufügen. Diese findet man hier: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" (Der Blocked-Schlüssel existiert möglicherweise nicht). Indem man dort beliebige CLSID-Werte hinzufügt, kann man verhindern, dass die zugehörige Shell-Erweiterung geladen wird. Ich würde argumentieren, dass dies besser ist, weil damit explizit angegeben wird, dass sie blockiert wird, anstatt einfach einen korrupten Wert hinzuzufügen, der einen Fehler verursacht, wenn die Komponente erstellt wird.
Aus irgendeinem Grund bestehen die Blogposts und "Artikel", die darüber sprechen, darauf, {86ca1aa0-34aa-4e8b-a509-50c905bae2a2} hinzuzufügen. Das "funktioniert" wahrscheinlich, weil die neue Menü-Shell-Erweiterung versucht, sie zu laden, und fehlschlägt, wenn dies nicht möglich ist, aber es scheint keinen vernünftigen Grund für diese Wahl zu geben. Ich habe einige Tests durchgeführt und es scheint einwandfrei zu funktionieren, die von Ihnen erwähnte CLSID als Wert dort hinzuzufügen, um die neuen Kontextmenüs im File Explorer zu deaktivieren.