Unfortunately, I don’t have a simple answer to this question. The documented traffic_sign=* minilanguage is too rigid for the U.S. and other countries with similar sign systems, so I don’t use it at all.
For starters, this syntax assumes a very simple design in which a sign can have at most one slot for freeform text. The MUTCD and its regional variants define hundreds of signs with more complex layouts. For example, this is a single sign with ten variables:
This is a single sign that allows a variable number of rows:
This is a sign that contains another sign (the 
state route marker) and is read nonlinearly:
These slots are unordered and can certainly contain punctuation like ,'":;()[] that breaks the syntax. Instead, I pair a simple sign code with the alternative syntax that relies on secondary keys for iterative refinement. For example, here’s a standard street name sign (which can come in one of a few standard colors):
traffic_sign=US:OH:D3-H6b
name=Patterson Road
operator=Franklin County
colour=green
I appreciate how this approach reuses existing OSM tagging conventions instead of inventing one specific to traffic signs. But each sign requires different tags. That same street name sign is likely mounted on the same post as a sign for a different street maintained by a different agency, even pointing in a different direction. The vast majority of traffic sign posts in the U.S. hold a stop sign and two “blade” signs pointing in different directions:
To prevent mixups between the various signs’ tags, I map each sign as a separate node in the same location with differing layer=* tags, placing only a single sign code in traffic_sign=*. I don’t have a good answer for how to indicate that the signs are mounted on the same support=post/street_lamp/tree, other than performing a spatial query to determine that they’re less than a few centimeters apart.
When I proposed formalizing this approach on the wiki talk page, @Kovoschiz pointed out that separate nodes make it more difficult to determine that a plaque modifies the sign above it. This is true, but I think we should encode the effect of such relationships on the usual roadway tags, for example with except=* on a turn restriction relation. In my view, traffic_sign=* tagging is mostly for presentational purposes, such as plotting signs on a map or displaying them in a car’s heads-up display. If it matters, we could come up with a more explicit tag to indicate that the sign modifies a sign represented by a different node. (In the MUTCD, the sign code for a plaque almost always has a P suffix, but I wouldn’t want data consumers to rely on that detail.)