Long rant, please bear with me. Filing this as a bug report as I'm certain it contains at least some unintentional behaviour.

With an item ('1.') and its child item ('1.1.') in a grid, I get the following drag and drop results (with both the source grid (SG) and the target grid (TG) being based on Y/N source fields):
A. Drag and drop 1.1. to become a top level item in TG ► 1.1. remains a child item under 1. in SG, i. e. it is visible in both grids.
B. After that, in TG, drag 1.1. to a child position below any other top level item in TG ► 1.1. is now removed from under its parent in SG, i. e. it now appears exclusively in TG. Why does a drag within one grid have an effect on the status of another?
C. After step A., with 1.1. now both a top level item in TG and a child item of 1. in SG, drag the top level instance of 1.1. in TG back to a top level position in SG ► 1.1. now exists twice in SG, both as a TLI and a child item of 1. Instead of the last action here, drag the top level instance of 1.1. in TG to a lower level position in SG ► 1.1. now exists twice in SG, as a child item in two different places.
D. After step C, drag the top-level instance of 1.1 in SG to a child position in TG ► There are now three instances of 1.1: top level in TG, top level in SG, child level in SG.
E. After step D, drag the top-level instance of 1.1 in TG to a child position in TG ► The item disappears entirely from TG instead of becoming a child item at the drop position. We're back to the state after step C.
F. From the original position with 1.1. starting out as a child of 1 in SG, drag 1.1. to any child position in TG ► 1.1 is immediately removed from its child position under 1. in the source grid.

Also generally, drag any top level item from one Y/N grid to another and it will be removed from the SG and only be visible in the TG.

Is this the way it's supposed to work? I doubt C, D and E are intentional. B. probably happens because you're supposed to be able to assign an item to a field by dropping it as a top level item in a grid, I get that. However, it seems to me that this makes drag and drop a dysfunctional chimera that is supposed to 1. assign field values to child items without removing them from under their parent in the SG but for TLIs removing the source field value (see step E. above; this alone seems inconsistent and confusing) and to 2. assign a parent to an item either in the same grid or another - but not to remove the current parent if the item is dropped at top level.

Thus we get (please correct if not wholly adequate):

1. Move TLI to TL in other grid ► remove from SG and re-assign to TG (no parent info to change)

2. Move TLI to child level in same grid ► unassign from SG *only if that is its source value but not if the value was assigned later* and replace item's parent

3. Move TLI to lower level in other grid ► *do not* unassign from SG and replace item's parent

4. Move child to TL in same grid ► assign to SG *and* remove item's parent

5. Move child to TL in other grid ► re-assign to TG but *do not* remove item's parent

6. Move child to lower level anywhere ► do not re-assign anything but replace item's parent

This is further complicated by the fact that demoting a TLI within the same grid will remove the source field value in a Y/N-source grid but will not in a date-source grid. Why? Also, when a date-source item is dragged to a child position in a  Y/N grid, it keeps its source date. Upon then being promoted to top level in that grid, it also keeps that value, being assign the Y/N field value of the target grid on top. I know this is done to preserve "more important" (date field) data as opposed to "less important" data (Y/N field) but I'm finding this really confusing / inconsistent in practice.

To conclude, the current state of affairs seems more less impenetrable, with results being highly inconsistent. I think the main thing that is bugging me is that when I drag a child item to anywhere in a different grid, I'd want it to be removed from the source grid in all cases (i. e. for TLIs, clear the source field value no matter its type, and for child items always clear / replace the parent field). If I wanted to add a value to a child or parent item rather than replace it, I think I'd prefer to use the Properties Pane or some other method. I'd be happiest if it worked the Windows File Explorer way, with regular drag being "move" and something like control-drag being "copy" or "add value".

Maybe this "Explorer mode" could at least be implemented as an alternative option.

Thanks for reading!

PS: Can illustrate some results with screencast(s) if the written version is painful to follow.