In 5.0 it's possible for spells lose or gain haste while being channeled or cast. An example of this is a warlock with Kil'jaeden's Cunning who starts to move while a spell is casting or channeling. When he does so his cast will start to delay by 20%. Also, in the case of ticking spells, ceasing movement will cause the spell to regain that haste back after a tick. So, spells can both accelerate and decelerate mid-cast.

Currently, the oUF castbar behaves somewhat okay for channeled spells that undergo this process, but the cast bar does jump around wildly when this happens which does not happen in the default UI. Non-channelled spells interpret this much worse however, resulting in a cast bar which jumps forward and ends far too early after losing haste. I noticed that Blizzard's casting info functions will return different (earlier than the actual time) start values, etc. when this occurs which may not be being taken into account.

Guessing it doesn't.

There is users reporting this as well on our forum.

http://www.tukui.org/forums/topic.php?id=22646

Actually the report on the forum was directed at the handling of
CHANNEL_START
CHANNEL_UPDATE
CHANNEL_START
CHANNEL_UPDATE
CHANNEL_UPDATE
CHANNEL_STOP

This is chain channeling which results in no lost DPS. For example you channel (at 0 haste) Drain Soul until 7.1s left, recast Drain Soul (you get the event chain above) and the new Drain Soul channel will be 13.1s long, with the first tick happening at 12s left.

The issue here is that UnitChannelInfo() in the CHANNEL_START event will return 12s and only be updated to 13.1s on the first and second CHANNEL_UPDATE events (no idea why but those CHANNEL_UPDATE events have slightly different start/endTime, same difference between them though).

The issues for Elv are that

1. The idea of chain channeling doesn't even seem to exist for SetCastTicks() - as in adding 1 extra tick at the beginning of the channel (1.1, 3.1, 5.1 etc). It does exist and has been in the game since the start of Cata I believe. It was put in to mimic the cast queue for cast time spells.
   Also, due to this, the existing ticks are quite badly offset so serve no real purpose.
2. The new duration of the channel seems to be treated as a delay, which it isn't.
   Seems pretty stupid of Blizz to do it this way but it looks like they give you the spell with CHANNEL_START (it includes hasted duration but no extra tick) and then send over the actual start/endTime in a CHANNEL_UPDATE event, which would require recalculating a lot of stuff on the bar.

This no dps loss mechanic only happens if you recast a channel while channeling the same spell.

I attempted a fix but got stuck on UnitChannelInfo() giving the bad data on CHANNEL_START. I'm just too unfamiliar with lua and WoW API and elv code to make a proper fix in decent time.
Should be doable if you detect the chain channel and redraw the ticks in CHANNEL_UPDATE.
tickSize = baseTick/(1+haste)
extraTickSize = channel_update_duration - tickSize * (baseTicks + hastedTicks)
Then start drawing the bars from extraTickSize value.

The [original] problem seems to appear when you recast while having KC up. there's a desync of endTime information between server and client - server thinks it should last a lot longer.
Also when you get KC up, stop cast, cast you can get pretty large desyncs between debuff duration and self buff duration for the channeled spell. I think it tries to slow the slowed spell then unslow it then slow it again.
It makes me think there are bugs on the mechanic itself, on top of the crappy event generation.

Does this still happen on live?