This is my partial list for procmail warts. To quote the jargon file:
wart n. A small, crocky feature that sticks out of an otherwise clean design. Something conspicuous for localized ugliness, especially a special-case exception to a general rule. ...
If you can think of a way to resolve any of these in a backwards compatible way that doesn't create any new warts, please email me about it. It is expected that some of these may require a redesign of the interface to fix, in which case they'll have to wait.
multiple mailbox action limitation
You can specify multiple mailboxes to deliver to in a single action only if they are all directory (including MH-style) mailboxes. This is because procmail just hardlinks the files when multiple directory mailboxes are specified. Arguably, procmail should continue to do that and if one or more non-directory mailboxes are included, procmail should perform separate deliveries to them. Since this is an obvious solution, this entry should probably be on the todo list instead of the warts list, but I don't feel like placing it there yet. There's a mild gotcha with this solution: currently the action folder will make folder a simple file folder (mbox-style) if it doesn't already exist, while the action folderA folderB will create folderB as a directory folder if it doesn't already exist. Should that behavior be maintained, or should the latter case create folderB as a file folder?
Also, how should the | pseudo-folder be handled when encountered later in the action line? Ick. Maybe this is just a bad idea after all.
formail & headers that only contain a space
formail -I"foo: " adds a header with just a space in it. This is not entirely obvious, as that may be part of an action that said formail -I"foo: ${foo}" where foo turned out to be empty. Perhaps the -z flag should suppress headers containing only whitespace that are being added?
leading newline weirdness
Procmail handles the matching of leading newlines (via ^ or $) by acting as if text being matched had a newline before it. This causes problems with conditions like ()\/.*$.*$ which try to extract pairs of lines -- the earliest match causes that regexp to only extract the first line (the first .* will match nothing and the first $ will match the putative leading newline). Changing that regexp to ^^\/.*$.*$ makes it work, but it doesn't keep this from being a wart.