string questions

[Dave Kemper]

I have a couple questions about groff strings.

1. In its section about the \* escape to interpolate a string, the
current manual text states, "The delimited form need not use the
neutral apostrophe; see *note Delimiters::."  But the example above
shows [ and ] as delimiters, and in fact single quotes (neutral
apostrophes) do not seem to work as \* delimiters:

$ cat test1
.ds mystring hello
\*[mystring]
\*'mystring'
$ groff -Tascii test1 | cat -s
hello mystring'

The output indicates that groff is parsing "\*'mystring'" as a(n
undefined) string called "\*'" followed by the text "mystring'".

Is this reference to neutral apostrophes an error, or is there some
aspect of this I'm not understanding?

2. The manual also states, "In contrast to macro invocations, however,
a closing bracket as a string argument must be enclosed in double
quotes."  But in practice this seems to be true of not just a closing
bracket on its own, but anything containing a closing bracket.
Observe the difference:

$ cat test2
.ds mystring2 hello \\$1
.nf
\*[mystring2 world]
\*[mystring2 "]"]
\*[mystring2 "\[aq]"]
$ groff -Tascii test2 | cat -s
hello world
hello ]
hello '

$ cat test3
.ds mystring2 hello \\$1
.nf
\*[mystring2 world]
\*[mystring2 "]"]
\*[mystring2 "\[aq]"]
\*[mystring2 \[aq]]
$ diff test2 test3
5a6
> \*[mystring2 \[aq]]
$ groff -Tascii test3 | cat -s
troff:test3:6: error: newline character not allowed in escape sequence parameter
hello world
hello ]
hello '
hello

Is this the expected behavior?  The error message in particular gives
little indication of what the actual problem is.  (This behavior has
been the same since at least groff 1.19.2, though after 1.22.4 the
error text was tweaked, now saying "escape sequence parameter" where
it used to say "escape name.")

More significantly, it's unclear why "\*[mystring2 \[aq]]" shouldn't
be parseable.  Clearly a "]" on its own needs the quotes to
disambiguate it from the closing bracket of the \* escape.  But the
opening bracket of the inner "\[aq]" ought to be able to tell groff
that the next closing one is associated with that escape rather than
with the outer one.

So, is the fact that this doesn't parse as expected a bug?  Or is this
not supposed to work, but the error text is suboptimal for explaining
the problem?

Thanks for any insight.