Currently the StarterGui loads each player’s gui as a result of that player’s character loading. This is a bit unintuitive because most people don’t consider the ui to rely on the character. It also requires odd workarounds for cases such as loading characters based on game functionality rather than autoloading characters. In addition, when able, the StarterGui seems to load each player’s gui before each character spawns anyway (and sooner than a script is to do the same).
It is unlikely that the current behavior will be changed because of backward compatibility concerns. However, a new property of the StarterGui such as “PlayerLoadGui” could be added that would allow opting in to this new functionality (similar to a few other such properties that avoid breaking backward compatibility).
A player must have a character before any GUIs in the StarterGui will be copied into the PlayerGui, regardless of the two properties. The suggestion (if I’m not missing the point here, regardless, this is a valid point) is that this not be the case. A player shouldn’t need to have a character for GUIs to be copied into their PlayerGui.
Correct, the point is that the character not be associated with the gui and rather the player. The suggestion is a property that enables such functionality as to not break any existing games that rely on or expect the character to be what causes the gui to be created.
As a note, its commonplace in advanced games to place the gui elements in ReplicatedFirst/Storage and copy them over manually to get around this. However, in a perfect world this shouldn’t be necessary, as this is the job of StarterGui.
I think the issue of no guis loading without a character is actually a bug, not an intention. I wrote a hacky fix for this a while ago but never shipped it. @Osyris might have been working on the new fix for this?