extracted trailing newlines

OK, folks, this is with procmail 3.11pre7.

Yes, if the regexp that sets $MATCH ends in a newline, the trailing newline
in $MATCH does survive when MATCH is saved in another variable, with or
without quotation marks.  Ed Sabol's expectations were on the mark ... when
the newline is really in the search area.  For example, in

 :0
 * ^Subject: *\/[^ ].*$
 { subject=$MATCH }

(where the search area is implicitly H) $subject does contain a hard newline,
and you can even use

LOG=$subject

and get a newline in your logfile without having to write

LOG="$subject
"

as we usually do.

But when it is extracted from a search area that does not end in a real
newline, and the trailing $ in the regexp matches a *putative* newline
instead, the closing putative newline is *not* extracted into $MATCH.

LASTFOLDER does not have a real trailing newline.  No, really, it doesn't.
Honest.

So if we want to reduce a path to its basename and it might have more than
one slash, this _does_ work:

  :0
  * LASTFOLDER ?? ()\/[^/]+$
  { BASENAME=$MATCH }

And so does this:

  :0
  * LASTFOLDER ?? ()\/[^/]+^^
  { BASENAME=$MATCH }

Further experimentation shows that if there is a closing real newline in the
value of the variable, with this condition

  * variable ?? ()\/[^/]+$

MATCH includes the newline, and this condition

  * variable ?? ()\/[^/]+^^

fails, as the character next to the terminating ^^ is a newline, which does
not match [^/].  But LASTFOLDER does not include a trailing real newline.

So Ed and I are both right.