Assuming the issue is related to June only having 30 days, which then pushes it to the next month July.

<?php
  2 //Expected 30/06
  3 echo date('d/m', strtotime('+1 MONTH'));
  4 //Result 01/07
  5 
  6 //Expected 30/06
  7 echo gmdate('d/m', strtotime('+1 MONTH'));
  8 //Result 01/07
  9 
 10 //Expected 01/06
 11 echo date('d/m', strtotime('first day of +1 month'));
 12 //Result 01/06


Could be safe to assume that the function should check the limits of each month to prevent it from going past the extreme.

Reproduced May 31st, 2013, CentOS 64Bit, PHP 5.4.15:
foreach (['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 
'Nov', 'Dec'] as $monthName) {
    echo "getdate(strtotime('$monthName'))['month'] = " . 
getdate(strtotime($monthName))['month'] . "\n";
    echo "getdate(strtotime('$monthName'))['mon'] = " . 
getdate(strtotime($monthName))['mon'] . "\n";
}

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

PHP date functions will overflow out of bound values: since June 31 doesn't 
exist, it becomes July 1.

How this is an overflow issue:

$timeStr =  strtotime('Jun'); // just 'Jun'
$date = getdate($timeStr);

The date represented by $date should be in June, but it's not.
Since I didn't specify a day it shouldn't be an overflow issue.
If the day is assumed/implied by the current day then that should be documented.
I would argue that since it is not specified, the 1st of the month at 0:00:00 is 
the safest assumption.

This is standard UNIX behaviour. You need to be explicit as you discovered. Try 
the same thing in a shell script, for example:

$ date
Fri May 31 16:37:45 PDT 2013
$ date --date='+1 month' +'Next month is %B'
Next month is July

SQLite and many other tools you will come across follow this same standard 
behaviour when it comes to data manipulation. It is described by GNU here:

http://www.gnu.org/software/tar/manual/html_node/Relative-items-in-date-
strings.html#SEC120

There is really no good answer to this one. We can't just assume the 1st of the 
month, because then adding 1 day would be equivalent to adding 1 month on the 
last day of the month. That's a huge amount of data loss. So we follow the 
UNIX/GNU convention.

Fair enough. Thank you both for taking the time to respond to this.

I would love to see the docs updated to be more specific about this.