My own usage falls more in line with the intent of the patch than
opposing it.  I have not studied the details and hope that an ab initio
perspective is useful.

Basically, I have groups with 3 different settings:

 no auto-expire (INBOX, etc. for real mail - I manually delete)
 auto-expire (mailing lists, and I tick things I want to keep)
 total-expire (spam, other low-value stuff like daily output mail)

Sometimes mail gets miscategorized by procmail, either because of spam
filtering errors (both ways), header regexp hairiness, or because I was
in To: in list mail.

What I do is "B m <group-where-it-belongs>".  When mailing-list mail
ends up in my INBOX or spam (I filter at 1 SA point, so people using
junky MUAs from yahoo end up there), I generally have glanced at it
enough to know I don't care and want it to be marked expirable in the
mailinglist group.  If I wanted to keep it I'd tick it right there.  I
do want to put it in the mailinglist group because I want the next day's
bayesian training run to pick it up as ham; it might have just been
learned as spam.

If I move a message from a mailinglist group to another group, I'd like
the E flag to be set as if the message had been there in the first place
and then read.

I realize other people might not like this.  So I think what's needed is
a global variable

  expirable-per-destination

that if t means that the expirable mark on a message which is moved to a
destination is set according to what it would have been if

  the message had been in the destination in the first place

  the message has been read or not read there, based on whether it was
  read or not read in the group it was in before.


Operationally, I think this just means.

  if expirable-per-destination

    messages moved into auto-expire groups
      set expire-flag if read-flag

    messages moved into other groups
      clear expire-flag

  else

    status quo


People that don't like this can just not set expirable-per-destination.