Ich finde diese Idee sehr gut

Großartiger Vorschlag Jastro! Klappt nur leider nicht . Windows gaukelt mir absichtlich vor, dass ich eben jene Schreibrechte bereits habe, um zu vermeiden, dass Viren oder sonstige Malware einfach abfragt, ob sie schreiben darf, und bei Bedarf halt "Gegenmaßnahmen" ergreift. Wenn ich mich in reinem Windows bewegen würde, könnte ich eine sogenannte "Permission Elevation" beantragen bzw. von vornherein verlangen, dass der Launcher nur als Admin ausgeführt werden darf. Da der Launcher aber zwecks Wiederverwendbarkeit unter MacOS ebenfalls in der Unity geschrieben ist, klappt das nicht. Daher auch die Empfehlung, *nicht* ins Programme-Verzeichnis zu installieren.

Auch auf die Gefahr hin mich zum Obst zu machen, fallen mir 3 Dinge dazu ein:

1. Lässt es sich nicht leicht prüfen ob man Schreibrechte hat, indem man eine Dummy-Datei mit einem Dummy-Text erstellt, deren Existenz/Inhalt man anschließend überprüft?

2. Kann man nicht durch eine Abfrage prüfen ob man sich gerade auf Windows oder MacOS befindet und je nach Situation andere Dinge tun?

3. Haben andere Unity Programme nicht das gleiche Problem?

@1: Der Trick von Windows ist, dass du ja vorgegaukelte Schreibrechte hast, nur werden die Sachen nicht in den eigentlichen Programme-Ordner geschrieben, sondern in einen "Virtuellen" Ordner, der nur bis zum Programmende und nur für den aktuellen Prozess verfügbar ist. Windows ist da - kreativ geworden.

@2: Doch, natürlich, jederzeit sogar. Aber die Dinge, die man tun können müsste, sind eigentlich schon bei der Programmerstellung zu machen, und die übernimmt Unity. Klar sind Betriebssystemweichen theoretisch machbar, aber wir bewegen uns außerdem noch in Mono und nicht in C# .net, d.h. da kommen nochmal andere Einschränkungen zum Tragen.

@3: Der Fall, dass auf das Programme-Verzeichnis geschrieben werden muss, gilt nur und ausschließlich für den Autopatcher. Und Unity geht offenbar nicht davon aus, dass Software auch aktualisiert werden muss, bzw. nimmt für diesen Fall eine "das geht uns nix an"-Lösung an. Das Problem dabei ist, dass die Veränderung *mancher* Dateien nicht virtualisiert ist, und so Teile der Daten (wie zB die Texturen und die Ressourcen) sehr wohl geändert werden können, das eigentliche Programm (also die DLLs) werden aber virtualisiert, sodass man dann eine "halb aktualisierte" Version der Schicksalsklinge nach dem vermeintlichen Update hat, die logischerweise gar nicht funktioniert.