The total damage redirected is capped by the paladin's health. Therefore, in a 25 man raid, you would be able to redirect only about 1.5k damage per person (25*1.5k = 37.5k and that's talking about a prot paladin using it). The 150% cap has been confirmed to kick in regardless of bubble being up or down. Bubble being up simply means you don't get insta-gibbed.

DiSac redirects the same damage type, so for example on the Cat Lady boss pull you can HoP + DiSac to prevent the damage. However, you may want to cast DiSac a few seconds pre-pull so you don't lose HoP while DiSac is up (both 10 second buffs).

There aren't many ways to implement a skill like Divine Sacrifice and the big issue with all the ways of implementing such a skill is that events that effect Divine Sacrifice tend to happen simultaneously. This implies that regardless of latency (which I will get to later), Divine Sacrifice will ALWAYS absorb more than 150% of the Paladin's health. Latency means that even after Divine Sacrifice has absorbed more than 150% of the caster's health, the buff might still remain on some players, affecting the amount of damage they take (and hence, what is recorded in the combat log).

Divine Sacrifice Algorithms

There are a few ways to implement a skill like Divine Sacrifice, but most of them probably look like the one I'm about to describe. When the Paladin casts the spell Divine Sacrifice, he becomes the focal point of an aura centred on himself that affects all people in a 30 yard radius. These people gain a buff that negates 30% of the damage they would have taken without the buff (in other words, it is applied last). Prior to 3.1.0, this damage was simply applied to the Paladin. If the Paladin died, the aura dissipated and combat proceeded as normal. This skill largely resembled Soul Link, but for the entire raid with the Paladin as the HP sink. In 3.1, the developers, seeking to nerf the efficacy of this skill imposed a cap on the amount of damage redirected.

There are a number of ways to implement this. They are likely to be variants on these two forms:

1. One could assign a "HP bank" with 150% of the Paladin's HP, sort of like Power Word:Shield. Every time someone takes damage, 30% of the damage is taken out of the bank, up to the point where the bank is empty. This damage is applied to the Paladin. When the HP bank is depleted, (that is, someone tries to draw out more than is in the bank) then only the remainder of the HP is redirected out and the buff is removed.

2. One redirects the HP as in 3.1.0, but keeps a running total of HP redirected. When amount of HP redirected exceeds 150% of the Paladin's HP, the buff is removed.

Method 1 is accurate. Method 2, however, is simpler (that is faster) and has the advantage of being able to be built on top of existing code. Also, given the available evidence (has anyone ever seen a parse where "odd" amounts of damage were absorbed?) it's strongly likely that Method 2 was used. In fact, odds are that at one point, the running total was maintained by checking the amount of damage Divine Sacrifice did to the Paladin, but then, the developers realized that Divine Shield was negating the damage entirely.

Simultaneity

Each person's total HP is likely maintained by one or more threads that don't have anything to do with other peoples' HP. Each thread independently tracks a shared resource shared by all the other threads (either the status of the HP bank or the running total of HP absorbed). So, when simultaneous events occur, each thread performs the operation on the HP total they are tracking and then they reconcile it using a different process. This process gives rise to a race condition.

For instance, let's assume that you have a raid of 26 people (for nice, easy numbers) with the same amount of HP and zero latency. The boss they are fighting has a skill that removes 10% of everybody's maximum HP every second for 12 seconds. The Paladin, seeing this, casts Divine Shield followed by Divine Sacrifice before the first tick. It's pretty obvious what should happen here: every second, the Paladin redirects 3% x 25 = 75% of his maximum HP; after two seconds, everyone has taken 14% of their maximum HP while the Paladin has negated 150% of his own maximum HP worth of damage, so Divine Sacrifice ends. This is true regardless of what algorithm is used to track Divine Sacrifice.

Now assume the same raid above, but that the Paladin has one more hitpoint than the other people in the raid. After two seconds, the paladin has redirected (150%-1) of his HP, so there is still 1.5 more HP to be absorbed.

Under Method 1 of implementing Divine Sacrifice, each thread has a copy of the HP bank saying that there is 1.5 HP left to be absorbed, so when the third tick happens, everyone takes 10% of their maximum health less 1.5 HP. Everyone draws 1.5 HP out of the "HP bank", they reconcile and there's a negative amount of HP in the bank. Ideally, you'd reconcile this too, and reassign damage to whoever's in the raid, but this is a real time application and there are more important things to keep track of. Besides, such a reconciliation would have to show up in the combat log and you'd look bad when HP levels start fluctuating due to "reconciliation". So you let it go. In the end, the Paladin casting Divine Sacrifice has redirected 150% of his HP plus an additional 36 HP.

Under Method 2 of implementing Divine Sacrifice, each thread has their copy of the running total of HP as being less than the maximum amount to be absorbed. They redirect 30% of the damage taken to the running total. When the running total is next reconciled, the total amount of HP redirected has exceeded 150% of the HP of the Paladin. Divine Sacrifice is removed and the Paladin has effectively absorbed 225% of his total HP (less one).

As you can see, under either method of doing this the Paladin has redirected more HP than the skill says it will.

Latency

It's fairly well known how WoW handles buff removal. In the case of Divine Sacrifice, it's most likely implemented as an aura centred on the casting Paladin. When Divine Sacrifice is removed by damage, the server "dispels" the buff from the Paladin. Without the aura, the buff is removed from everyone else in the raid. This means that a message saying "remove Divine Sacrifice" gets sent from the server to the Paladin's client removing the aura, which generates an acknowledgement from the Paladin's client to the server, who then sends a message to all the other people in the raid telling them to remove Divine Sacrifice, which they acknowledge, after which no more damage is being redirected by Divine Sacrifice. This process can take a while depending on latency. In the meantime, the Divine Sacrifice buff is still up.

If Method 1 of implementing Divine Sacrifice is used, then you get periods where the Divine Sacrifice buff is present, but no damage is redirected. This shows up in combat logs and you look bad.

If Method 2 of implementing Divine Sacrifice is used, damage is redirected until this process is complete. (Much) more damage is absorbed than implied by the tooltip and you get lots of speculative posts on forums about how Divine Sacrifice works...

Conclusion

Snark aside, it is difficult to conceive of a method by which the folks at Blizzard came up with a way to perfectly implement a skill like Divine Sacrifice (at least with the technology they have today). Regardless of how it was implemented, it would nearly always redirect more HP than advertised while at the same time being sort of a resource hog and generating bizarre looking combat logs for us users to pore over.

On an interesting note tonight I found that Spiritual Attunement is not impacted by the Generals mana-regen-crippling aura.

The build previously mentioned by myself, is terrible in usage. We dropped a healer and the builds reactivity was just too slow to use. Can't imagine that would get any better till you get to ridiculous levels of haste. Cheers