Hi @Florian-Schoenherr,
Not sure i fully follow. Is this a feature request/ a question/ something else.
any of the above is fine, i just need some help so i can respond properly.

all of the events emitted by the library include the id of the dragged item (under info) which can be used to retrieve the index very easily. alternatively, it can be added to the info very easily if needed. no one has asked for it so far.
Internally the library tracks the "would be index" during drag operations in order to decide when to emit which event.

regarding the whiteboard. i will need some more info or an example in order to respond.

You probably know apps like diagrams.net/excalidraw/miro.com (although they differ in implementation). I want to use something like that, but also want to use your "sortable-list"-type dnd.
Let's say I have 3 cards, which I drag around with absolute positioning (like miro, ..).
Now I want to drag one card onto another and that's where your dndzone should kick in. If I then decide to drag one card out of your dndzone (which has 2 cards) and just "onto the whiteboard", it should be positioned absolutely again.

That would mean we'd need something like dropinside, dropoutside and the current position of the dropped element. If that's out of scope, it's okay.

"Whiteboard" would then mean, maybe we want a completely separate "dnd-absolute" for absolutely positioned elements and then people would be able to drag&drop between your dnd and "dnd-absolute"? Maybe I'm overthinking.

this type of "whiteboard" drop zone makes different assumptions than a sortable dropzone.
For example, a sortable dropzones assumes elements can't overlap (the centre of the dragged element can never be over two elements at the same time). In a white board they can, which brings the stacking order into the equation (which element should be drawn on top of which etc.).
Keyboard interactions might also be different, as well as aria labels and messages.
This mix might be possible though with some tinkering, assuming your app implements the whiteboard part. The tricky part is of course crossing the border of the whiteboard in and out (each one requires a different handover)

That's the thing. I wouldn't want to re-invent the wheel (although I tried - but barely working).
It's fascinating how hard that stuff gets.

Stacking order is not needed in my usecase (although if there should potentially be a component that others can use, people would need it).
I think both are pretty different, the whole sorting stuff would be left out, for example. Maybe a second, separate action would be "cool". I think I can't get my head around it completely, but I will try building something and if you have an idea (for the handover), please tell me.

You may know this kind of implementation for finding containers under a dragged element:

node.hidden = true;
let elemBelow = document.elementFromPoint(event.clientX, event.clientY);
node.hidden = false;
if (!elemBelow) return;
let droppableBelow = elemBelow.closest('.droppable');

I could potentially abuse this, with a .whiteboard container.
If you drag out of the dndzone onto .whiteboard, erase the item and put it into the whiteboard-items. If you move a whiteboard-item over your dndzone (with class .dndzone), erase the item and put it into the dndzone-items.

@Florian-Schoenherr
I played with it a bit and got a super primitive version going in this REPL.
The whiteboard is the square on top and there is a normal list below.
If this is roughly what you are after (a polished version of this that is), the library can probably provide some extra data in its events that makes this easier.

Wow, thank you! I made an implementation too, without the dndzone on whiteboard. I used TRIGGERS.DROPPED_OUTSIDE_OF_ANY. Gonna REPL when it's done.

(Just realized your solution has the advantage of sorting when dragging the element from whiteboard to dndzone.)

REPL.
Only thing missing is the dragging of the container.. and code looks messy.
You can see my usecase a little better there, try dragging one out and then one onto the other.
More nesting is not neccesary, the container can be pretty dumb, it should only update itemGroup.x&y.
I tried some stuff but there was always something missing, it didn't react or I had something wrong, maybe.

so u want to be able to put one item inside another...
the top level items (parents) are always movable on the "whiteboard" to wherever but the children need to be sortable within each parent?
in other words, the only thing missing in your example is the initial parent container being draggable to wherever, right?

Yes, if you have two or more items in a group, you should be able to move the group, too. I gave the .droppable a margin so that you can drag it's parent, in reality it would be more obvious. Using a dndzone for it doesn't work because it drags inside itself, into the inner dndzone (or something, it throws many errors).

@Florian-Schoenherr you might find this conversation relevant.

Errors REPL
(I haven't added the changing position of the container)
Dragging the container inside itself:

I didn't look deeply yet but position:absolute shouldn't cause issues (my example of whiteboard had it) and nesting shouldn't either (ex: crazy nesting). what can cause issues is if dom elements (zones or children) and added, removed or rearranged without the data that is passed-in reflecting that.
if you have a chance please have a look at my proposal (i included a link above) and let me know if u think it addresses your need.

Yeah, the inner consider/finalize is probably triggering when I drag it inside itself, that's my fault. Also I haven't added the position:absolute container dragging