introducing an 'AnimationPlane' may solve many problems#5

An animation plane would be a stack in a provider that encompasses the view (either the whole window, or the nearest scroll view), which animated widgets can place themselves into and then remove themselves from once they're complete. The AnimationPlane provides a stable coordinate system to rely on while the coordinates of the immediate container may be changing due to size changes or sudden movement, addressing #2. It would also address #4. It would also make removal alignment more robust, able to handle center-aligned and spaceBetween aligned animated containers. It can at least catch removal animations, and ideally it would also catch transfer animations, animations where an item moves from one animated container to another, during which the item has to render above either of the containers, so it has to be in a shared common AnimationPlane. Without AnimationPlanes, I don't know how we'd do transfer animations at all. ideating { What if there were a layout animation target, and a layout animation follower that could be put in any AnimationPlane. The target is read each frame by an active follower and its position is relative to the follower is calculated and the follower positions itself within the AnimationPlane, until the animation is complete, at which point the widget is painted normally, and the follower is deleted. } (this mirrors https://api.flutter.dev/flutter/widgets/CompositedTransformFollower-class.html ) One problem is... removal animations need to go behind the rest of the contents of the animated container, but not behind its container. So if you just had a plane behind everything that wouldn't work. So maybe you'd have one plane per container, but those planes would be able to relate to a root plane (the scrollview level plane) and position contents relative to that even if the plane moves?