The pdfroff program is supposed to handle multiple passes of groff to produce and combine table of contents and body text in the order expected by those not familiar with groff (and troff), that is contents first, then body text. For those not familiar with troff, by itself doesn't do multiple passes when building the document, so it traditionally produced the table of contents at the end of the document, after it had collected all the section titles and their page numbers. Since output primarily to paper originally, it was easy to manually move the piece or pieces of paper with the table of contents up to the right spot in the document.
It occurred to me that the way to avoid this weird behavior was to use the documented option to disable the double pass mechanism, and it worked.
pandoc -t ms --pdf-engine-opt --no-toc-relocation -No manual.pdf manual.txt
I guess the other behavior was designed with titlepages in mind, while the default document type in pdf/groff puts titles on the first document page.
So it seems to me that this switch must be added to the command line call to pdfgroff to produce an output consistent with standard groff.
Besides, there may be a way to add or remove support for titlepages, just as in *LaTeX. I may try to do that to the ms template in a couple of days in a fork.
I've not used pdfroff myself (despite having used troff extensively from before there was a groff), so I wasn't sure what the combination of pandoc and groff were supposed to produce in this case, but found the blank page and the two pages being numbered 1 surprising, and thought someone might know off hand what to expect here.
I think I just have figured it out.
I should at some point read the pdfroff man page in detail and figure out what it's normal use produces and then figure out what is happening in this case with the pandoc output, but I'm suffering from an extreme lack of round tuits, though not interest, right now.
I have a working hypothesis it -_o
Cheers!