Ich glaube, die Absicht war es, Cut/Copy/Paste direkt neben dem Mauszeiger zu platzieren, unabhängig davon, wie das Menü erscheint. Die "Toolbar" zeigt sich unten, wenn der untere Teil des Menüs mit dem Zeiger ausgerichtet ist.
Ich habe den Eindruck, dass einige der Leute, die diese Designentscheidungen treffen, ehrlich gesagt jünger sind und vielleicht mehr Erfahrung im Bereich "Webdesign" haben, weil solche Dinge immer wieder auftauchen, wo es eine klare Absicht dahinter gibt, die eigentlich gut wäre, aber die Umsetzung lässt zu wünschen übrig, weil die Auswirkungen einfach nicht ausgearbeitet sind. Dies ist keine Ausnahme.
Wie du erwähnt hast, lässt das Icon-Design im Kontext viel zu wünschen übrig, da sie im neueren "Designsprache" eher amorphe, formlose Klumpen sind, die nicht für eine Darstellung in dieser kleinen Größe konzipiert wurden. Persönlich finde ich es schwieriger, auf den ersten Blick zu erkennen, um welche Option es sich tatsächlich handelt, bis man sich die Zuordnung der formlosen Klumpen gemerkt hat. Ich muss mit der Maus darüber fahren, um wirklich klar zu sein, welche Optionen verfügbar sind.
Ein weiteres Problem ist, dass nicht verfügbare Optionen überhaupt nicht angezeigt werden. Das verstößt gegen ihre eigenen Richtlinien, da nicht verfügbare Symbolleisten-Schaltflächen deaktiviert sein sollten, und Cut/Copy/Paste werden speziell als "Gruppe" von Befehlen genannt, bei denen alle sichtbar sein sollten, auch wenn einige deaktiviert sein müssen. Das Hauptproblem dabei ist, dass die Position der Befehle unvorhersehbar ist. Wenn Cut/Copy/Paste immer in einer bestimmten Reihenfolge wären, könnte man die Symbole eher ignorieren, aber da sich die Position der Symbole basierend auf dem Zwischenablagenstatus ändert, ist das nicht möglich.
Das gravierendste Problem dabei ist, dass die Implementierung einzigartig für den Datei-Explorer ist. Cut/Copy/Paste in Kontextmenüs erscheinen in praktisch keiner anderen Anwendung, die jemand jemals verwenden wird, also geht es nicht nur darum, "Windows 11 zu lernen", sondern vielmehr darum, dass dieser bestimmte Teil von Windows 11 jahrzehntelangen Kontextmenü-Gewohnheiten aus fragwürdigen Gründen, die selbst von den Mängeln in der Implementierung überschattet werden, völlig ignoriert.
Amüsant finde ich auch, dass selbst innerhalb des Datei-Explorers selbst dies nur für Kontextmenüs von Dateien verwendet wird. Wenn ich Text in der Adressleiste auswähle und mit der rechten Maustaste klicke, sind Cut/Copy/Paste normale Menüoptionen. In meinen Erfahrungen scheinen auch die Öffnen/Speichern-Dialogfelder dies nicht zu haben.
Das Menü selbst hat auch ein fragwürdiges Design. Einer der Gründe, warum es eingeführt wurde, scheint zu sein, dass das "alte Kontextmenü zu überladen wurde". Und da ist sicherlich etwas Wahres dran, aber ihre "Lösung" für dieses Problem ist nur kurzfristig; das neue Menü ist nur "unüberladen", weil weniger Anwendungen es unterstützen. In Zukunft, wenn mehr Anwendungen es unterstützen, wird es sich auf die gleiche Weise überladen, also haben wir dann zwei überladene Menüs.
Für mich persönlich: Ich benutze StartAllBack, das es ermöglicht, das Kontextmenü des Datei-Explorers zurückzusetzen. Ich glaube, es ist auch möglich, das Menü zurückzusetzen, indem man einen Dummy-Wert zum Registrierungseintrag hinzufügt.
Im Wesentlichen fügt man einen Schlüssel "{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" unter HKEY_CURRENT_USER\Software\Classes\CLSID hinzu und erstellt dann darin einen InProcServer32-Schlüssel. Dadurch wird die Klassenregistrierung von HKEY_LOCAL_MACHINE überschrieben, sodass Windows Explorer beim Versuch, die COM-Komponente für das Kontextmenü des Datei-Explorers zu erstellen, fehlschlägt und auf die Standard-IContextMenu-Implementierung zurückfällt.