At least during the opening cutscene, you cannot assign it. I am defensively assuming that there can be other situations where it's broken as well.
If this is actually a bug, and it is intended to always be assignable, then that's just that. A fix would be nice.
But if not, that's opening a whole new can of worms. I will try to explain.
If assigning to it is not reliable in all cases, then that means the on_gui_closed event is basically broken because it's unreliable as well.
Consider a mod that has a typical button at the top of the screen, which toggles the mod's "main UI window". If that's opened during a time when player.opened is broken (i.e. cutscene), then the window will be visible (since its creation code will run fine), but the game does not keep track of it whatsoever, so on_gui_closed is not fired when E is pressed etc.
It also means you can open multiple of these kinds of GUIs simultaneously during that time, even if each individual mod has programmed their GUI "correctly".
How bad it is depends on how the mod implements the GUI. If it's just keeping one global permanent GuiElement instance per player, and just toggles the visible property (like many of these typical top-of-the-screen buttons happen to be implemented) then it's not that bad. If it's actually creating a new window each time and assigning player.opened, then it's proper scuffed and you can flood the screen with windows.
When I started out I initially assumed that the API design is such that writing to player.opened would be the way to open a (pseudo-)modal window which behaves exactly like the "E" window (instead of adding it to player.gui.something directly). This particular problem could not have existed that way, but the API would feel different in some other ways.
Note that flib's gui library does not work around this successfully either. I have not seen a bug-free implementation yet.
The player.opened/on_gui_closed mechanism is unreliable
Re: The player.opened/on_gui_closed mechanism is unreliable
One way to prevent this is to check the player controller before making the GUI to open. Another option is to check if player.opened == the element which was just assigned. Theoretically, there is no "perfect" way to detect an element closes, or is even *destroyed*, considering any mod can interact with all luaguielements at any time. Unfortunately there is no "on_player_controller_changed" event, too
I have mods! I guess!
Link
Link