As I've been wrestling with an annoying niggle, I thought I'd post my various findings here, in case they're useful.
Note that several things have changed since my last (2018) post, not far above this one, including which mobile device (and browers upon it) I'm using. And that I am satisfied that all my various issues (like the continuing [abbr] incomplete functionality) are at my end.
Basically, the [font]-tag is entirely dependant upon the reader's system taking the paramaterised 'suggested' font that is supplied (via simple HTML) as the font-family style parameter to a <SPAN>. As with the Wingdings, above, it works when it can work. Other tags, when translated, specify (directly and/or via CSS) a fuller font-family, particular ones that are specifically fixed-width users. Again, it depends upon the end-user's system, but it at least includes multiple fallbacks.
Test .W_- font=courier - fails to become Courier-like on this browser+device, after invoking any font-family style for the sole parameter (browser/device issue)
(Note that I haven't discovered any cascaded use for the bbc_font class that this could invoke, but it wouldn't help this issue much anyway, the way it 'works'.)
Test .W_- font=courier new - fails on this browser (could it work with quotes passed around to multiword style?)
[font="courier new"]Test .W_- font="courier new"[/font] - entirely fails to parse as BBCode (doesn't appear to like me giving it quotes to transform into the HTML form)
Test .W_- font=monospace - works on my device, though it's a sub-sized font in direct comparison with non-monospace of same pointsize spec. Unknown if "monospace" is universally acceptable, though I think it'll have a decent chance to widely so.
Test .W_- code-tagged
- invokes DIV-nested style that specifies a thorough font-family listing that works, even if just upon the one last listed (monospace). But doesn't help with SPAN-type inline styling.
Test .W_- tt-tagged - 'normal' fixed-width (calls bbc_tt style in CSS; full family list with monospace but renders larger than font=monospace, so may be one of the other after all). I shall probably use this option more in future, though it isn't rendered via any 'editor' button so is slightly fiddlier.
You, dear reader, may have entirely a different set of results for everything I describe in this post. Which is more a vanity project for myself than an instruction-manual.
And, while I'm here, I'll echo another recent conversation I had (with a fellow member of this parish) about the Glow and Shadow tags. They render badly here (i.e. this particular device, 2020-vintage rather than possibly half a dozen years older). Pinch-zooming indicates that they are placing correctly (Glow and Shadow layer sit behind, and slightly offset to, the primary version of the text) and the zoomed-in or font-upscaled effects are pleasant and readable (though may need side-scrolling!), but at 'normal' size the glow overdominates. A purple 'glow' behind a fuschiaedit: no, orchid I meant text just looks blurry purple (but then fuschiaedit: orchid! and purple are a similar hue). Changing to a 'red' glow for some notable contrast, the glow clearly dominates (it actually gives a rose-pink effect, but still looks just blurry). Giving a totally contrasting glow (e.g. green) makes it messy and blurry at non-zoomed appearance.
Obviously, again, somewhat specific to my device (and eyes), but FYI while this is all at the forefront of my mind. i.e. full standardisation/uniformity of presentation is a dodgy assumption to make, even these days. But I hope this helps someone else in some unknown future who goes looking for similar reasons for similar issues.