The question lacks important details, but it seems that the objects sharing the same interface are actually of different types based on clues like 'glyph' and 'hex' being strings.
The issue here lies in the fact that Protocol Buffers (GPB) thrives on strong typing; it is most effective when the schema provides a complete definition of the data. Using strings implies that the data will need to be parsed in some way, rather than clearly defined by the schema.
For instance, representing color as a string could be improved by using three integers for red, green, and blue values instead. A color name can be ambiguous! Is it a hex value or something else?
If the information in 'glyph' alone isn't sufficient to create an object, you risk separating vital details between the code and schema. While this may work for your own use, it could pose challenges if the data needs to be interpreted by a system written in a different language – they won't have access to your constructors!
A better approach would be to define each possible object thoroughly in GPB messages within a schema, then encapsulate them in an overarching 'oneof' message when sending. This ensures clarity on the object type and provides explicit data about it.
If the objects share similar content and behavior, creating a universal class to describe them all might suffice.
Your suggestion about serializing the map and transmitting it raises the importance of serialization methods; either enhance the GPB schema to accommodate this process or consider alternatives.