Justin, what I'd envisioned does not affect default behaviour at all, or at least very much. "remove" is called when an element is scheduled for removal and the original API such as length treats that element as if it's not even there. splice, pop and shift merely set up a transition listener. This needs to be View-Model.
For it to be View-only, using a modified event structure like that sounds as if original functionality would be changed, making it less seamless. The concept behind can.transition is that it can be easily swapped out if there is ever an issue.
Currently, the only issue I'm having is forcing a reflow for setting the "intro" transition. Extro/outro transitions work perfectly fine without any external intervention. I suppose that I could override can.Component with a new extended one that sets up a listener on "init" or similar for each of its can.Transition.Map/List instances. It's just that extending can.Component itself is messy, requiring lots of duplicated code that is not future-proof.