You talk about “meaningful strings”, but there is no formal definition of meaningful strings.
There doesn’t need to be a formal definition for “meaningful string” for how it has been used in the past 3 years and now, or how I see it being used in OpenZeppelin’s current upgradeable contracts. However some formalness could be added to it. Currently the EIP says “no whitespace characters”. It could also say no unprintable characters such as the null \x00, because there is no reason for meaningful strings to contain those. This can be enforced by tooling.
We are building tools that have to be robust and work with arbitrary Unicode strings.
Using keccak256 to hash meaningful strings is a robust way to create namespaces for structs. However you are right that strings with nonprintable characters or random strings are not “meaningful” strings.
You say that you need to work with arbitrary Unicode strings that are not meaningful. The current OpenZeppelin’s Upgradeable contracts are using meaningful strings. In what way are you currently using random or unmeaningful strings for storage of structs? Or what specific use cases do plan for this to be used for?
I argue that arbitrary or random strings are not namespaces because they aren’t names. Namespaces in software have transitionally been meaningful, not random or unreadable strings. I argue that a standard designed for unreadable or random strings should not be called a namespace standard.
Maybe there should be two standards here. One standard for unreadable or random strings used to store structs that clearly describes why it is useful and some of its use cases. And another standard that is a namespace standard that uses meaningful strings which is backward compatible with how namespaces/diamond storage has been used in the past three years and will not confuse people with hash manipulation that isn’t needed.
I disagree with the hash manipulation, specifically - 1) & ~0xff for a namespace storage standard to handle an edge case that nobody is using and no specific use cases have been described or given in the standard. I think that a new standard could be created in the future if this was needed that was very clear the specific use cases it was being created for, this way people are not confused with the idea that all namespaces need the hash manipulation.