Sorting is not the issue. He sort of a container doesn’t affect note position. More likely is due to dragging content into a container in a non-map view. All the latter requires is for the notes not to obscure/overlap—which they don’t in your grab. Of course, that isn’t what you imagined.
The safest way in this scenario, is to use map view. Select all the content except the new container and drag the selection onto that. Map position should be maintained, assuming the target container has no content. Why? Consider: what should the app do if dragged in content wants the same map position as content already existing in the content. Which moves (existing or added object) and to where. It’s less trivial than imagined, essentially with 100s of items rather than one ot two in a simple test.
I’m not suggesting the outcome you describe is good, just why.
It also why I’ve long been unhappy with the default doc tab being a map. It’s way too easy to add all sorts of data before realising you probably wanted to work inside a container.
Except doing so in Map view has no effect on the map. Agents will show their child aliases on a grid/sorted map view but this does affect normal containers.