The idea of changing .pl's behavior, as floated in comment #1, has now been spun off into bug #61453.  The present bug is now concerned only with disambiguating the documentation to better explain the current behavior.  That is, disregard comment #1 and read only comment #0.

Part of the .pl section of the info manual states:

Negative @code{pl} values are possible also, but not very useful: No trap is sprung, and each line is output on a single page

This contains a couple of ambiguities:

(1) "No trap is sprung": This wording makes it sound like this is referring to a specific trap; otherwise, it would say "no traps are sprung," or "no traps of type (x) are sprung."  But no specific trap is mentioned in this section.  The paragraph before refers to traps in a general sense for setting top and bottom margins; these are usually page-location traps, which indeed are not sprung with negative .pl values.  But input line traps, for example, are sprung.  I haven't comprehensively tested which types of traps are sprung and which aren't, so I don't yet have a suggested replacement wording.

(2) "each line is output on a single page": This could be read two different ways: all output is on a single, unending page; or each line of output starts a new page.  The second is what actually happens (which is an odd choice, as the first would be useful for TTY output, while it's hard to imagine a real-world use for the second--a fact the documentation even acknowledges by calling the behavior "not very useful"), so the wording should say this more unambiguously.