Thanks for the reply, Harlan.
I didn't think of Tags as having inheritance like Types provide inherited icon/labels/text color attributes. I guess since there's no "supertag" hierarchy with Tags, and Tags don't alter core Thought properties like Types do...
So, it's essentially as if the design were: a new Tag 'inherits' an icon from a single TB9-internal "superTag" (poetic license here to imply hierarchy/inheritance); that supertag has the pricetag icon. Text color is also inherited from internal defn (or maybe theme?), and Label inheritance doesn't apply (Tag Abbreviations are the corollary).
If so, I get it, but it still seems simpler to pre-populate the pricetag icon ... given the minimal Tag properties an no user-defined heirarchy/inheritance. Just my preference to potentially decrease some confusion. I can see the argument to not change anything, too.
Anyway, speaking of Tag display...I frequently pin all three of: Tags, 'regional hub' Thoughts, and frequently used Types on the top of the Plex in order to to quickly activate, link, and shortcut-assign (Tags, Types). I manually group-order these, L->R, Thoughts, Types, Tags. I do this, in part, because there is not pinned Tag differentiation from pinned Thoughts. In theory Tag/Thought icon/names could be the same. Conversely Types on the pinned bar are differentiated with the same dotted outline box as used in the plex (this is really nice!).
So, a suggestion is to consider visually differentiating pinned Tags from pinned Types and Thoughts; similarly, probably use the same differentiation for activated Tags in the plex, even though there is less need than plex Type-Thought differentiation.
Might also consider stating in the respective property boxes if a Thought, Type, Tag (akin to v8). I get the balance between TMI vs clean/minimal workspace...very common.
Again, thanks for considering.