I am against adding this to core. Symbols represent identifiers, not data/text. Strings should be used for data/text. I don't think we should add methods to Symbol that further blur the line between String and Symbol.
I would rather see :"#{s1}#{s2}" for explicitly combining two symbols in the few cases that need to do so. That would be slower than the cached approach as it currently results in 3 string allocations, but I don't think it is likely to be a bottleneck.
One issue with the cached approach you used is that the cache doesn't use a weak map, so dynamic symbols that use + would never get garbage collected.
I agree with benoit and jeremy, also in regards to the use case description; even speed/cache considerations aside, matz
possibly may consider the proposal to not fit into/to class Symbol by default. It is actually already awesome that class
Symbol can be modified like this :) - I am not sure if it is required to add '+' to class Symbol as a method, by default.
I can understand it somewhat to some extent (people love Symbols ever since the old pickaxe, I guess), but I think what
benoit wrote is quite true - it may be better to be conservative here and keep Symbols and Strings distinct as separate
entities. (See also what matz wrote about the origin of Symbols for ruby).