Describe the bug
When dragging a motion.ul element i expect the children motion.li to also be dragged along. This works fine directly after mount, but as soon as we update the state of the component, the list elements becomes static.
I first suspected it was just something I'm missing in the new API, so I wrote a question on Stack Overflow. But after simplifying it further, and comparing with version 1.11.1, I now suspect this is a bug.
IMPORTANT: Provide a CodeSandbox reproduction of the bug
https://codesandbox.io/s/framer-motion-reorder-animation-go6tb
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
I expect the colored boxes to behave the same before and after the shuffle. This worked in version 1.11.1 (only code difference is using positionTransition instead of layout prop):

Video or screenshots

Environment details
Windows 10
Chrome Version 83.0.4103.116
Maybe a better example:
https://codesandbox.io/s/framer-motion-reorder-animation-dhfw2
In this example the button simply sets some local state that is not used anywhere. In other words, all it does is trigger a rerender. Still the dragging stops working after clicking it.
After a render layout projection has been enabled so elements are trying to project themselves to a specific place on the viewport.
At some point soonish I want to look into resolving these bounding boxes relatively to parents so I imagine this will fix that.
Seems like this was fixed in version 2.4.0, Thank you!
@micnil Would you mind reopening this issue? Although it seems to have fixed the case in your example, #663 still appears to be broken.
Thanks
Updated my codepen with a failing example here:
https://codesandbox.io/s/framer-motion-reorder-animation-forked-j4blh
It seems it is still broken if both the draggable parent and children have the layout prop set. In my original example only the children had the layout prop set. I assume this is what the problem is with #663
I think I have the same issue. I have a flex layout where the sidebar animation happens through layout.

And this is the exact same, only with a layoutId applied to the third blue square (to make a iOS home screen-style transition into a modal):

As is visible, it now performs an unwanted transform correction for the parent, making it jump to the end position. When I override the element with transform: none !important, it transitions nicely as in the first example.
Temporarily overriding with transform: none !important worked as a workaround during animations, but I'm now running into the dragging issue as well.
Most helpful comment
After a render layout projection has been enabled so elements are trying to project themselves to a specific place on the viewport.
At some point soonish I want to look into resolving these bounding boxes relatively to parents so I imagine this will fix that.