Looking at this a bit more, it seems like the main problem is that drop locations are determined by polling the entire list of sortable items looking for the 1st one that overlaps the dragged item. 'Overlaps' here meaning that a 2d collision test is done vs the absolute position of the item.
In addition to being hugely inefficient, it's wrong when one of the items is obscured by a scroll pane.
There are at least two solutions to this: One would be to search for the sortable target first, and then only do the item shuffling logic on those elements. The other would be to sort all of the items by position, return all of the items that overlap the dragged item, and then make a decision about which one is the most likely candidate.
I'm hoping the new version doesn't rely on finding the location of every item on the page at the beginning of every drag event, so it seems like sorting the items is probably the wrong solution.
As to a workaround for this bug: I think I may have identified one, but I still need to implement it and write it up.