While looking into this one, I spotted few interesting things.

Patch for this is:
- if (color > -1 && color<im->colorsTotal && color<=gdMaxColors) {
+ if (color > -1 && color < im->colorsTotal && color < gdMaxColors) {

Besides "color<=gdMaxColors" check, there is also "color<im->colorsTotal" check.  GD code also assumes that im->colorsTotal is <= gdMaxColors, as it is used as an upper bound in multiple cases when accessing arrays of gdMaxColors size.  You can see "im->colorsTotal<=gdMaxColors" enforced in e.g.  gdImageColorAllocateAlpha(), which is called for PHP function imagecolorallocate().

Hence:
  color<im->colorsTotal (from the check)
and
  im->colorsTotal<=gdMaxColors (assumed in the rest of the code)
implies
  color < gdMaxColor

So the change should not really introduce any extra protection for current
PHP versions.

This change is relevant for pre-4.3.5 PHP versions, which do not have "color<im->colorsTotal" part of the check.  It is possible to trigger im->alpha[] off-by-one over-write in those versions.  This changes neighbor member of the gdImageStruct structure - trueColor.  If that happens, gd will believe that previously non-TrueColor image is now TrueColor, which can lead to buffer over-reads or over-writes in subsequent gd operations (due to a different storage space needed for pixels of TrueColor and non-TrueColor images).

But there is also concern for current PHP versions, as im->colorsTotal may be initialized with a value greater than gdMaxColors when using imagecreatefromgd() PHP function on a specially  crafted GD file.  Value read from file is not properly checked in _gdGetColors() (gd_gd.c),possibly allowing previously mentioned over-reads or over-writes on various places (e.g. colorsTotal is used in _gdGetColors() when initializing im->open[] with 0s).  CVE-2009-3546 was assigned to
this problem and the fix is now committed in PHP SVN:
  http://svn.php.net/viewvc?view=revision&revision=289557