I've never seen it either and found it to be immediately clear. I wonder what similar prefixes could be used for "libre not gratis" and "libre and gratis". I know that "Free" could stand in for the second, but it's more ambiguous than "$free" was in this article.
Systems have a way of finding fall-back fonts. At least on OS X (err, macOS) they will satisfy glyph requests in order from the font you specify, some built-in fonts, and then any fonts that have the required glyphs. Finally, a "last resort" font is used to fill in any remaining glyphs[1].
A result of this is that if you ask for a character such as "𓀴" (U+13034 EGYPTIAN HIEROGLYPH A044) in a monospace font, the symbol you get back can be variable width.
Then you run into problems with how characters are represented. For instance, é (lowercase latin e with an acute accent) can be represented either by one unicode codepoint (U+00E9, 'LATIN SMALL LETTER E WITH ACUTE'), or by two unicode codepoints (U+0065 U+0301 -- LATIN SMALL LETTER E, COMBINING ACUTE ACCENT). There are normalization forms that will convert these two representations into the same representation for easier comparison.
If you don't perform canonical equivalence checking, you could search for "café" and not find a file named "café.txt" if it uses the other representation.
I'm so glad to see auto-vectorization happening more and more often. However, I wonder whether a language that had built-in support for primitive floating-point vector types (e.g., GLSL's vec3, vec4, mat3, mat4) could help the compiler with performing these sorts of optimizations.
I'm only posting because the plural of anecdote is data.