Thanks for that PR, I was too lazy to do it myself 😄
Internally, the item is already being removed from the player's inventory by setting its type to air and amount to 0 so you don't need to remove it yourself though

I don't think slot related methods are a good idea
having methods for itemstack and equipment slots cover basically all needs

I don't think slot related methods are a good idea having methods for itemstack and equipment slots cover basically all needs

The issue with that is that dropping by ItemStack pretty much always forces the first ItemStack to be dropped. Dropping by slot allows to choose an explicit one, like the one current held, as example

Internally, the item is already being removed from the player's inventory by setting its type to air and amount to 0 so you don't need to remove it yourself though

That sadly not the case for items equipped on armor. I am not quite sure why, but in my testing, armor items did not get cleared by themselves

Internally, the item is already being removed from the player's inventory by setting its type to air and amount to 0 so you don't need to remove it yourself though

That sadly not the case for items equipped on armor. I am not quite sure why, but in my testing, armor items did not get cleared by themselves

in my tests it worked (1.21.1 and 1.21.3)

I don't think slot related methods are a good idea having methods for itemstack and equipment slots cover basically all needs

The issue with that is that dropping by ItemStack pretty much always forces the first ItemStack to be dropped. Dropping by slot allows to choose an explicit one, like the one current held, as example

I did not think of that
in that case, it totally makes sense

in my tests it worked (1.21.1 and 1.21.3)

When I remove that line, it turns into an dupe glitch 😥

@EventHandler
public void onInventoryClick(final InventoryClickEvent event) {
    if (!event.getClickedInventory().equals(event.getWhoClicked().getInventory())) {
        return;
    }

    event.setCancelled(true);
    event.getWhoClicked().dropItem(event.getSlot());
}

hmm i see

Oops, the patch has a problem. Give me a second to fix it

Now let's wait for a maintainer for review

Instead of the persistThrower boolean, I would find an optional UUID argument allowing you to directly set the thrower more useful. Especially given that method already exists on the resulting Item entity anyways.
Also some Javadoc clarification on what throwRandomly does surely would be helpful, without looking at the NMS code I have no clue what that would do.