We have many named symbologies that use very similar text settings. These appear to be an ideal location to implement the use of Text Styles. Most of our text styles have the Color check box clear (un-checked) but when selected within the Named Symbology editor, the color is changed to match the color which is listed in the text style. Many of these text elements in InRoads are labels for survey points. Making the label color the same as the survey cell makes it easier to match the text label to the point. This behavior makes the use of text styles very limiting.
This also illustrates other issues within InRoads. In a number of locations within the product, we are finding it necessary to create whole families of named symbologies because a single setting of a symbology must be different to function. Sometimes its the justification, other times it's a left or right offset.
This adds significantly to the number of named symbology choices required when defining some display setting and also means that if you need to change a standard, you have more places to edit.
I suggested some time ago having the capability of setting a named symbology, and when you do, all of the settings in the dialog box gray-out, but next to each one is a check-box. Clicking on a check-box would enable an "override" for that setting. I even suggested how this would be recorded in the XIN. When a named symbology is currently used, the XIN replaces all of the various symbology settings with a single entry of NamedSymbologyName Name=... - To add overrides, they could support the inclusion of the override field name and value, or add an ExtendedSymbology node containing the override names and values.
Of course, all of this assumes the XIN file format will persist for the near future (and hopefully, for the long run) which a recent post appears to put that assumption into question.