Hi everyone,
Kevin mentioned in the 4145 release notes that “spacing changes depend on how you move an element.”
It’s a little easier to see that in action than describe it, so I’ve recorded a 3 minute video. It covers a few things to keep in mind with spacing, size, and positioning when you are moving elements around different layouts. Check it out and let me know if you have any questions.
How are you getting the space between elements (pink lines and values in pink boxes) to show?
Edit: Disregard, I found it’s the HUD text in the top right of the UI.
Yep, the HUD button. 
The HUD will also come up automatically (even if the button isn’t activated) when you’re moving elements inside of a stack or grid, or into other elements, as per the above video.
After watching the video, I wanted to suggest a way that I believe - if feasible - may make preserving an element’s relative position within a new parent more intuitive: instead of the only way to do this being to drag an element over the tree, can a modifier key be used to trigger the same functional action? In other words, with no modifier key pressed, the element drops as expected; with a modifier key pressed prior to and during the drag and drop, it is as if the element was dragged and dropped over the tree.
We knocked around that idea on the initial implementation. I think our concern was that modifier keys are getting a bit crowded and we’d rather punt on assignment rather than have to change it in the future.
Another related action that I can imagine wanting a modifier key for is convertign elements between self-directed and parent-directed on drag. E.g. I draw out a freeform box and then want to insert it into a stack.
It’s definitely something we’ll keep in mind.
It seems that for me the expected behavior is that all of the settings I applied to the object will remain intact, instead of resetting to preserve the previous size.
For me, the whole point of the app is reducing manual adjustments and free positioning is the special case. Not the vice versa.