Hi Michael,
Thanks for spotting this. Will correct. Other than  that, I've never been a big fan of these arithmetic operations on ranges. They don't meet any of the basic expectations one would have about arithmetic operations in general:
(a) When multiplying by some value, the interpretation of the sign of the value is counter intuitive:
  ir <- IRanges(120, 131)
  ir * 4
  # IRanges of length 1
  #     start end width
  # [1]   124 126     3
  ir * -4
  # IRanges of length 1
  #     start end width
  # [1]   102 149    48
So using a positive value a divides the "half width" of the original object by a and using a negative value actually multiplies it by abs(a).
(b) It turns out that multiplying by 0.25 works and produces the same result as multiplying by -4:
  ir * 0.25
  # IRanges of length 1
  #     start end width
  # [1]   102 149    48
and multiplying by -0.25 also works and produces the same result as multiplying by 4.
Ranges should really expand when multiplied by a value > 1 and shrink when the value is < 1. Multiplying by a negative value doesn't need to be supported. Division should probably be supported as a convenient way to shrink ranges e.g. ir / 4 (same as what ir * 4 currently does).
(c) Addition is inconsistent with multiplication: adding a positive value expands, a negative one shrinks:
  > ir + 2
  IRanges of length 1
      start end width
  [1]   118 133    16
  > ir - 2
  IRanges of length 1
      start end width
  [1]   122 129     8
The result of this is that interaction between addition and multiplication is not what I would expect. I would expect this
  (ir + 3) * -2
  # IRanges of length 1
  #     start end width
  # [1]   108 143    36
to be equivalent to this:
  (ir * -2) - 6
  # IRanges of length 1
  #     start end width
  # [1]   120 131    12
but it's not. It's in fact equivalent to this:
  (ir * -2) + 6
  # IRanges of length 1
  #     start end width
  # [1]   108 143    36
I think these were introduced a long time ago to provide some convenience in the context of interactive visualization but I wished they had adopted a more conventional semantic. I would discourage people from using them programmatically since we might want to revisit their semantic at some point. I'll add a note about this in the man page.
H.