Ok, first things first, this is half a duplicate of MC-108. You see, that bug covers everything, and this would be a bug even if that is valid behavior.

The problem I am having is that due to hash order (or something strange like that), dispensers can "latch" until they receive a block update. You can achieve this by building something like this:
   ◨██__
☲☲   ██
(☲☲ is a dispenser and ◨ is a button)
The first time you press the button, the dispencer fires.
The second time, it doesn't.
Even I, normally 100% for quasiconnectivity, can tell this is a bug.
What is likely happening is that on the tick where the button turns off, the dispenser is updated once, but it sees that it is still powered by the not-yet updated redstone dust. The redstone dust then gets updated, and turns off, but doesn't update the dispenser (due to quasiconnectivity updating behavior). The dispenser then thinks it is powered on the tick, because it hasn't realized it isn't. Then, when you press the button again, the dispenser is updated. It realizes the dust is off (since the redstone seems to be updated second), but the button is now on. This didn't occur in the past due to the dispensers firing again when powered behavior, but now it does occur. (I tested this with a 1.2.5 jar, and it worked properly).
This shows how hash order still is important. (I say hash, but I mean update. No idea where I got that behavior.)
The fix isn't necessarily to return the firing again behavior, I know it was removed due to block updates triggering it, but if the dispenser is powered again on the same tick it is unpowered, it should fire.

If you have any questions post them in the comments.