Because I love crosslinking:

comment #6:

> I want a `for` request that will iterate over macros/strings/diversions,

Bug #62264

> and new conditional operators to test for "nodes" and for glyphs
> that are actually defined in the current font,

If either of these have tickets, I can't find them.

comment #9:

> comment #8:
> > This would be a simple iterator.  The string named "s" takes on the value of each item in string-expr from left to right.
> How is string-expr tokenised?

Sorry, I wasn't thinking properly when I typed that.  (Haven't actually tried to implement this yet.)

The second argument would need to be a "name", so a string/macro/diversion.  Attempting to iterate over an undefined one would probably throw a "mac" warning.  Attempting to iterate over a request would be rejected with an error.

> What do you mean by contrivance? AFAIK, most of the characters documented by groff_char(7) have corresponding entries in the UCD.

I'm starting to remember what I wanted the really-a-glyph predicate for.

See bug #63354.  There's a lot to it.

> No no, I only mentioned that to elucidate my remark about "too many hours coding in PostScript".

Ahhh.  No worries.  :)

comment #7:

> comment #6:
> > Long stories short, I want a `for` request that will iterate over macros/strings/diversions
> Interesting. Does it resemble this?

Not closely.

What I had in mind was this.

.for s string-expr \{\
.  whatever
.  you
.  want
.\"  break
.\"  continue
.\}

This would be a simple iterator.  The string named "s" takes on the value of each item in string-expr from left to right.
 

> > and new conditional operators to test for "nodes"
> YES. PLEASE. The whole "nodes versus strings" semantic is what led me down the aforementioned rabbit hole. The fact I even got it working (without GNU extensions, no less) is a testament to my neurotic stubbornness.

Yes.  People keep doing complicated, wacky things to work around this.  Keith Marshall has his "sanitize.tmac".  I have two different instances of loony shit in an.tmac and doc.tmac to abbreviate overlong material for placement in headers/footers.

It's incredibly tedious and bug-prone.
 

> > and for glyphs that are actually defined in the current font
> I've probably spent too many hours coding in PostScript, but wouldn't an escape sequence that expands to the name of the font containing the requested glyph be more useful?

Maybe.  But the question I've found myself needing to answer recently was "is this REALLY a glyph the font will provide, or some contrivance in the *roff language?".  I forget now where this came up but it's in a Savannah ticket.  Dave might remember.

> At least that way you'll be able to compare the output against the name of the current font.

Not saying this isn't worth doing, but it's not one of the two big changes mentioned above, and which I would like to do soon.
 

> (This corresponds to PostScript's `where` operator, which locates the entry on the dictionary stack which defines an entry with the given key. I'll shut up now)

By the time a request can process something in *roff, there aren't many stacks of interest to look at.  Just a node list.

*roff was written for small systems. There's no Document Object Model.  The formatter has no view of the whole document at any time.  It keeps track of as little as possible; enough to spit out the next output line and a few other bits of state demanded by features required to typeset conventional works.

comment #5:

> The projected likelihood of introducing such a backwards-incompatible feature is marginal at best, and indicative of feature creep at worst.

Muahahahaha.  You don't know of my plans for groff 1.24.

Long stories short, I want a `for` request that will iterate over macros/strings/diversions, and new conditional operators to test for "nodes" and for glyphs that are actually defined in the current font, as opposed to interposed via character definitions.

I'm working on this on a (so far, local only) post-1.23.0 branch.

Here's what I have at the moment.

diff --git a/doc/groff.texi b/doc/groff.texi
index 15b3cd8a3..ae5645c63 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -12571,8 +12571,19 @@ certain other @code{troff} implementations.@footnote{This refers to
 @code{vtroff}, a translator that would convert the C/A/T output from
 early-vintage @acronym{AT&T} @code{troff} to a form suitable for
 Versatec and Benson-Varian plotters.}
+@end table
+
+If the first argument to an @code{if}, @code{ie}, or @code{while}
+request begins with a non-alphanumeric character apart from @code{!}
+(see below); it performs an @slanted{output comparison test}.
+@footnote{Strictly, letters not otherwise recognized @emph{are} treated
+as output comparison delimiters.  For portability, it is wise to avoid
+using letters not in the list above; for example, Plan@tie{}9
+@code{troff} uses @samp{h} to test a mode it calls @code{htmlroff}, and
+GNU @code{troff} may provide additional operators in the future.}

 @cindex output comparison operator
+@table @code
 @item @code{'}@var{xxx}@code{'}@var{yyy}@code{'}
 True if formatting the comparands @var{xxx} and @var{yyy} produces the
 same output commands.  The delimiter need not be a neutral apostrophe:
diff --git a/man/groff.7.man b/man/groff.7.man
index 0d0539a98..dec4deefd 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -2099,9 +2099,20 @@ T}
 .
 .
 .P
-The first of the above,
+If the first argument to an
+.BR .if ,
+.BR .ie ,
+or
+.B .while
+request begins with a non-alphanumeric character apart from
+.B !\&
+(see below);
+it performs an
+.I "output comparison test" .
+.
+Shown first in the table above,
 the
-.I "output comparison operator,"
+.I "output comparison operator"
 interpolates a true value if formatting its comparands
 .I s1
 and

comment #1:

> I'm a bit dubious about this.  I have send elsewhere

s/send/said/

Also, if I find where I said this, I'll link to it.

And, finally, I didn't address `.if v`.

That's documented because we do support it.  If we didn't, the 'v' would be treated as the opening delimiter of a formatted output comparison operation, just like other letters that aren't conditional operators.

$ echo '.if z' | ./build/test-groff -ww -Tascii
troff:<standard input>:1: warning: missing closing delimiter in output comparison operator (got a newline)

Plan 9 (and by extension, plan9port and 9front) include a utility called htmlroff that adds a new single-character condition to its `.if`/`.ie` requests:

> Conditional input
> To make it easier to write input files that can be formatted by both troff and htmlroff, htmlroff adds a new condition h which evaluates true in .if and .ie requests. The t  condition continues to evaluate true, to accomodate input files trying to distinguish between troff and nroff. To write a conditional matching troff alone, use ‘*.if !h .if t*’.

Since groff(7)'s "Conditional expressions" section mentions the historical Vroff extension (`.if v`), it should probably also mention the unsupported htmlroff extension too (`.if h`), if only for completeness's sake.