Seriously, why wasn't this is v.0.0.1?? It's IMPOSSIBLE to debug a filter that has multiple regex, on a jail that watches multiple log files. The log file tells us the 'what' (the filter) but not the WHY (the failregex).

I have 24 logfiles in a jail, and 16 regex in my filter watching Apache. Am I really supposed to make a jail and filter for every possible combination just so I can heave meaningful output in the logs?

I don't think this option currently exists: Add the matching pattern to log file results, maybe like so:
NOTICE [poison-attempts] Ban 1.1.1.1 [<HOST> .*GET \/wordpress]

The ban occurs after several failures (corresponding parameter maxretry), which could be matched consecutively by several regex's.
Either it should be written within Found message (then it is exactly one matching regex), or it could be a lot of regex's in this message.
Additionally to write a regex in log after each ban may be too heavy (a number would be enough).

It's IMPOSSIBLE to debug a filter that has multiple regex

Well it is possible, but at the moment only at level 7, which would produce too high log-output.

And it is pretty easy to DEBUG the filter with fail2ban-regex. You'll see each regex with number of log-lines matched. Or simply try it with the message only, to catch the regex:

fail2ban-regex "$msg" 'filter[mode=...]'

Seriously, why wasn't this is v.0.0.1??

Because nobody needs it?
The filter for usage in production should be also production ready (and then there is simply nothing to debug).

One needs a failregex in fail2ban log, another needs a log-file name there (see #2393), and I'm pretty sure we'll get more RFE's in this direction in the future.