The GUID you mention in the namespace is actually the package localisation ID. It’s there to allow stable keys while editing text, and also to allow people to use custom keys for their text (since the conflict domain is limited to a single package) - these are both features that people have been requesting for a long time.
With regards to memory consumption, this change hasn’t actually affected that at all, as each identity has always had a unique display string, even when we collapsed things together for translation. The reason for this is that when performing a live-culture switch, we just update the display strings in-place and we don’t know which texts are shared in all cultures.
For our games, text doesn’t actually get duplicated very often due to the way our data tends to be organised. Game data is typically stored in Blueprints, Data Tables, or Data assets, and UI data is typically built up from component UMG assets, which results in the same text instance just being referenced or shared rather than repeated in assets.
I will state once again that the localisation system in UE4 isn’t designed to be used to author a string table as source text, and we don’t build it with such a use-case in mind. It is designed to let people author source text as source, without worrying about how the localisation system gathers and processes that.
I’m not saying we’ll never add dedicated string table asset type and integrate it into FText properties, but we haven’t yet because you can essentially make your own string table using a Data Table, where the row name is the key, and the row struct just holds an FText. Admittedly that doesn’t integrate nicely into FText properties, but you could easily expose a function to look-up a row from a given table, and use it in BP construction scripts, C++ constructors, and any other C++ or BP ‘getter’ code to resolve your ID to your text.