No, I was clear throughout, using the same arguments, that encoding things for the purpose of representing "empty", "full, "half filled" like if it was a nuemric gauge was a bad idea.
When I spoke about the various represetnations of gauges (including with photos) it was just to demonstrate that this is a domain where designers and authors are extremely creative, and there's absolutely no standard way of doing things right as each representation is a pure local decision. Just consider the case of the classification of hotels and campings: they are just given an integer number of stars, and whever these stars are white (hollow/transparent filling), black (completely filled), multicolor, or even half filled does not change the classification. Now if you think about half-filled stars, there are also the case of half-cut stars too (left side or right side shown) to represent as well half units. Or stars with only 1 to 4 branches filled, with variation about the position where branches are cut : in the middle of a branch, creating a thiner triangle. Or between branches (that are kept as complete diamonds extending up to the center. Variations as well in the number of branches for the star itself. (Someone here showed an example in Israel using 5-pointed stars, but in Israel, one could easily fing many cases with 6-pointed stars i.e. using the David's star, either dranw only on their external borders, or drawn as two intersecting triangles creating an hexagone in the middle). You could as well half-fill a star by varying the width of its border toward the center (still maintainning a "white" star in the middle) : such exampels are not difficult to find. Or by drawing a filled star in the middle of an outer thin border, whose size will vary from zero up to the outer border. Then you'll find the issue of text direction if you start making distinctions between left-half-filled and right-half-filled: CJK texts may prefer using an horizontal cut with top-filled or bottom filled (and this will be complicated by text orientation for the vertical layout, because typically Latin letters may be rotated, not CJK sinograms or Hangul syllable squares, but kanas in half-width form could follow the Latin layout (think about ruby notations), but not full-width kanas : how will you orient the stars, and where will you put the half-cut and which side will be filled ? For me all existing half-filled symbols that exist today are there for compatibility reasons with older terminal character sets. They do not have a true distinct identity. as they are completely dependant on their use of a monospaced font and the older terminal technologies where texts could not be reoriented. IF we need to encode new characters now, it is (hopefully) for allowing their use in today's and future softwares. plain-text only remains the worst case for presenting a document to a user, even if it remains as internal textual data : this data will be presented somewhere with some additional layout and styles and will be adapted for accessibility (but you can't design an accessible application if you just depend on pictograms with unclear semantics). For plain text even today, the best representation remains with using standard digits. For the rest, a star remains a star and its color does not matter. Not everybody will see it and then later, nobady will give hints about the value they represent if you need another non graphical representation : this does not occur with letters, digits, or currency symbols, which remain readable as such, independatly of their rendering style and used glyph, or independantly of the tool used to draw them : a brush, a rollpen, a grphite pen, a plum, will not be able to render the same kind of strokes and fills, and filling a form with a rollpen (or even more with a plum and ink) is a nightmare for handwriters that just draw want to strokes without filling them : they'll just draw a star, but if something more precise is needed to specify a numeric value, they'll write that value explicitly. We should only encode characters that users would reliably draw manually using a plum or rollpen, independantly of color, or of the width of the tool used to draw strokes, or possibly to fill them : basic orientation of glyphs however will be a candidate if its variation in the same text orientation is significant (this includes mirrored, or upside down characters, or significant changes of size and position relative to the baseline. Some exceptions are given to maths symbols (including letter-like) which are encoded specifically with their maths semantics for use in maths, but not for general purpose text. But can you only describe a well-defined usage pattern of these half-filled stars symbols in a domain so well described and defined like maths? I bet not simply because there's no standard and every author chooses what fits their own desires. A star is a star, just like a digit is a digit or a letter is a letter. And then an numeric value assigned to a symbol is just a numeric value: the assignment is not defined in any consistant standard, it may only be consistant in a single document. So it is an orthoginal property that does not depend on the glyph or even abstract character chosen to render it with styles. And we are clearly not in the same case as emojis that have a clear meaning by themselves as pictograms explicitly showing what they mean. : an angry face to mean angry for example, or a thumb up to mean the same gesture you would exhibit in real life, or a raining cloud to mean rainy weather. And a star to mean... a star.