I think this needs a test, no?

I don't think that this is right. It's the first removal without $animate that looks unnecessary.

But doesn't removing that open the door to orphaned elements sitting inside of the previousElements array?

Also, it appears that every single $animate.leave.then will attempt to splice off the same previousElements element, given that unless this is synchronous, i will always evaluate to selectedScopes.length - 1...

When removing that bloc:

Chrome 37.0.2062 (Mac OS X 10.9.4) ngSwitch animations should destroy the previous leave     
animation if a new one takes place FAILED

I think that is intentional. I think the solution here is to check. It shouldn't splice an element that was already removed, and it shouldn't remove an element that was already spliced ;)

However, the callback handler is incredibly erroneous.

yeah. that's what I saw too. @matsko is on it and will correct the test if needed.

So this should fix the closure issue. I do actually think that the $animate check is probably suboptimal in terms of CPU cycles, but does save a bit on memory. Just need a decision there ;)

@IgorMinar any thoughts? I can go ahead and patch up whichever way you guys think we should go with this. Or was @matsko addressing this issue himself?

@matsko already landed the fix, but I think you are right about the i in splice being always the same number at the time the callback is evaluated.

Maybe you could submit revert your changes, rebase and fix that. Or submit a new PR and close this one.

Sure. I am pretty sure his fix alone will actually cause a leak. This should patch it

I don't think we should create that extra closure function inside the loop. Instead how about:

var spliceFactory = function(array, index) {
    return function() { array.splice(index, 1); };
};

for (i = 0, ii = selectedScopes.length; i < ii; ++i) {
  var selected = getBlockNodes(selectedElements[i].clone);
  selectedScopes[i].$destroy();
  promise.then(spliceFactory(previousLeaveAnimations, i));
}

Although maybe V8 et al are clever enough to optimize it out at runtime.

Otherwise LGTM

I think this would not lead to a memory leak. The real problem would be that an animation may be cancelled twice if the wrong animation was spliced from the array. Still a problem but not as severe as a memory leak.