Confirmed.  The warning is spurious.  The documentation is pretty bit-rotted, or maybe started that way, and the logic in src/roff/troff/input.cpp is harder to follow than it needs to be.

Per the source code, four escape sequences permit newlines as delimiters.

I can check three of these against V7 Unix troff behavior, but \X is a device-independent troff innovation.

Interestingly (to me), \X is not documented even in the "Unix 4.0" version of CSTR #54, the earliest documentation of device-independent troff known to date.

https://lists.gnu.org/archive/html/groff/2022-06/msg00033.html

So it is really not clear to me whether it should accept a newline as a delimiter.  But, groff seems to have accepted it basically forever...

I'm working on a fix for the diagnostic messages.

Interesting, I don't see any fundamental behavior difference between 1.22.4 and git HEAD here.  In both I get the warning only if warnings are enabled; the only difference is that 1.22.4 emits a terser version:

$ printf '\o\no+\nOne.\n' | groff -ww | wc
troff: <standard input>:2: warning: missing closing delimiter
    236     630    5730

• If the documentation is correct, there should be no warning.
• If the documentation is incorrect, and newline is not a valid \o delimiter, the warning should not complain only about its closing delimiter.
• If the documentation is correct, but based on it recommending against this practice, a warning is emitted, the warning should tell the user "that's a bad idea" rather than "something's missing."

So no matter the situation, the current warning is inaccurate.  Updating Summary accordingly.