Gopal: should we just move this to a #ifdef _APC_DEBUG_?

Alternatively perhaps we should add an APC debugging level would be easy to integrate this into our apc_xprint functions.  Or perhaps it should just match that of the corresponding PHP error level?

Also do you really run into a case where you're flooded with these messages ie: you're doing multiple stores on the same value repeatedly?

There are code paths in some of the code that tends to generate quite a lot of apc-warnings. First it was 'realpath failed to canonicalize' and after upgrade I am seeing the cache slam warning. 

As it seems that some of the code seems to generate different warnings (and tons of logs) after upgrade I would like to disable these just all together if possible. 

Is there a reason why the apc errors don't go through the standard error reporting mechanism? Something like:

http://valokuva.org/~mikko/apc_error_levels_v2.patch.txt

with ability to disable apc-warnings/notices all together would be ideal solution in my case. One thing I didn't quite understand is that why does my_log fflushes stdout?

Yes this would not only very nice to disable apc-error messages. Than I could check last error message and generate a better exception message in my code like the following:

if (!@apc_store('test', 1)) {
    $lastErr = error_get_last();
    throw new Exception('Can\'t store apc key "test": ' . $lastErr['message']);
}

Such patches should not be accepted.
Disabling error output to hide bug is a very bad practice.

This 
apc_store("hello", 1);
..
apc_store("hello", 2);

must work in the first place (unless you are out of memory)

The APC user cache was not designed for short expiry entries 
like that.  So one fix would be to simply restrict apc_store() 
from setting a ttl of anything under 5 minutes.

Moved all error reporting to use php_verror (zend error reporting).

You won't see notices or warnings depending on error_reporting flags.