I've been doing some reading:
https://bugs.php.net/bug.php?id=45546
http://stackoverflow.com/questions/7620910/regexp-in-preg-match-function-returning-browser-error

and using test scripts, I can see that some requests can fill the 
stack very quickly while others never crash PHP. So, apparently it's 
possible to write regexps to be more stack limit friendly.

These tips seem to help:
- use possessive quantifiers where possible. This means: ++, *+, ?+ 
{}+ instead of +, *, ?, {}.
- move quantifiers inside of alternative-brackets where possible

That should be up to the programmer to determine.  I don't want the 
programming language enforcing arbitrary limits.

If a programmer wants to shoot themselves in the foot - that is their 
prerogative.  But this limit makes certain tasks impossible, 
especially when the input data size is unknown (say, for example, an 
e-mail message where the PHP programmer has no control over limiting 
this input size).
There is something wrong with your system then.  Because I can run 
with this number at 10,000,000 and nothing happens.

From the PHP documentation
"PCRE's recursion limit. Please note that if you set this value to a 
high number you may consume all the available process stack and 
eventually crash PHP (due to reaching the stack size limit imposed by 
the Operating System)."
Well 10000 makes IMP > 6.0 crash, so I'll have a chat with the 
sysadmin to see if he can find out why this is happening.

PHP is seriously broken if this somehow causes a segfault

It is generally accepted that addition of this recursion_limit was one 
of the worst core PHP changes that was made in the last few years.
5000 is **WAY** too low.  That value is going to cause all sorts of 
issues with any sort of even moderately complex regex that contains 
backreferences.  For that matter, 100000 is also arguably too low.

OK. The PHP dev team have shed some light on why this is happening.

The default pcre.recursion_limit in PHP is set to 100000.
This value is too high for my setup, for an unknown reason. It may be 
too high for other installations as well. This means that PHP will 
crash before reaching that limit due to other limitations.

Not sure if Horde should change its default settings, but for people 
running into the same problem, add this to the root .htaccess file:
php_value pcre.recursion_limit 5000

I've looked at the core dump
And one particular email with a very long list of recipient either 
makes PCRE crash

Starts with
#0  0x00000008006105e2 in match () from /usr/local/lib/libpcre.so.1
#7670 0x0000000802257bf2 in php_pcre_match_impl
#7671 0x00000008022585f8 in php_do_pcre_match
etc.

ends with
#7725 0x00000008025165a7 in php_execute_script 
(primary_file=0x7fffffffe170) at /php-5.4.9/main/main.c:2482
         realfile = 
"\360\333\377\377\377\177\000\000h\211\314\033\b\000\000\000\020\334\377\377\000\000\000\000\200\334\377\377\000\000\000\000\020\334\377\377\377\177\000\000\365\001\b\000\000\000\000\377\314\033\b\000\000\000\200\334\377\377\377\177\000\000\320\334\377\377\377\177\000\000\020\226\206\001\b", '\000' <repeats 12 times>"\335, \377\377\377\177\000\000\220\335\377\377\377\177\000\000 
\211\314\033\b\000\000\000\030\024\315\033\b\000\000\000\310l\266\001\b\000\000\000\340\020\315\033\b\000\000\000\217\334\377\377\377\177\000\000\220\334\377\377\377\177\000\000\372\231\207\001\b\000\000\000\340\005\315\033\b\000\000\000X\335\377\377\377\177\000\000\200b\017\001\b\000\000\000\300\334\377\377\377\177\000\000\240b\017\001\b\000\000\000\000\001\000\000\000\000\000\000X\370\260\005\b\000\000\000\000\002\000\000\000\000\000\000\260\005\261\005\b\000\000\000\000\223\317\005\b\000\000\000\020\002\000\000\000\000\000\000\250#\261\005\b\000\000\000\260\005\261\005\b\000\000\000\017\022U\002\b\000\000\000(\305)\347\265\b\255\262\260\005\b\000\000\000GX\270\035\343\236g\206\000\000\000\000\000\000\000\000\307"...
         __orig_bailout = 0x7fffffffe1f0
         __bailout = {{_sjb = {34398626970, 34407231968, 
140737488341896, 140737488347472, 34826363040, 0, 34826179216, 0, 
34407187071, 34826363040,
               34407230688, 34359738368}}}
         prepend_file_p = 0x0
         append_file_p = 0x1df4
         prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, 
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, 
isatty = 0,
               mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, 
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, 
closer = 0x0}},
           free_filename = 0 '\000'}
         append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, 
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, 
isatty = 0,
               mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, 
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, 
closer = 0x0}},
           free_filename = 0 '\000'}
         old_cwd = 0x7fffffffcba0 "/"
         retval = 0
#7726 0x000000080261d292 in php_handler (r=0x81bd020a0) at 
/php-5.4.9/sapi/apache2handler/sapi_apache2.c:667
         zfd = {type = ZEND_HANDLE_FILENAME, filename = 0x81bd2b560 
"/var/www/html/webmail/services/ajax.php", opened_path = 0x0, handle = 
{fd = 0,
             fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len 
= 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0x0},
               reader = 0x0, fsizer = 0x0, closer = 0x0}}, 
free_filename = 0 '\000'}
         __bailout = {{_sjb = {34399702360, 34450510960, 
140737488347480, 16, 34826363040, 0, 34826179216, 0, 895, 0, 
140737488347760, 34359738368}}}
         ctx = 0x81bd06de0
         conf = 0x81bcfe418
         brigade = 0x81bd00d98
         bucket = <optimized out>
         rv = <optimized out>
         parent_req = 0x0

Will check the PHP bugs DB

In other words: unless you can tell us exactly where in your 
installation's code this is being triggered, there's nothing we can do 
to help you.

This is, essentially, a segmentation fault.  So see:

http://wiki.horde.org/FAQ/Admin/Troubleshoot/IMP#toc14

And when it happens, it only happens with the INBOX folder.
Maybe there is something in the folder that the parser doesn't like.

I've found something in the Apache logs.
There is something Horde is doing which is making Apache or PHP crash.

AH00051: child pid 99220 exit signal Illegal instruction (4)

The server is running PHP 5.4.9.

What did change with IMP 6.0.1 in regards to the IMAP connector?

For further debugging information, please read 
http://www.horde.org/apps/horde/docs/INSTALL#dynamic-view-troubleshooting

A new bug has been introduced in 6.0.1.
The dynamic view crashes on some Inboxes. The basic view doesn't have 
this problem. The IMAP backend is Dovecot.

Steps to reproduce:
- Log in
- Click on Mail, in the main menu

After a few seconds, an error message appears
Error when communicating with the server.

The scripts that fails:
services/ajax.php/imp/viewPort

There is no error in the Horde or Dovecot logs, so not sure how to debug this.

JS/CSS is compressed but have been refreshed after the upgrade.