The onPlayerDeath event that is triggered by this mod is triggered through LivingEntityMixin rather than using NeoForge's LivingDropsEvent, which causes mods that would modify drops when the player dies to not get detected.

As an example, here is some code from Dragon Survival that adds some custom drops to the LivingDropsEvent due to a new piece of the player inventory:

    @SubscribeEvent(priority = EventPriority.HIGHEST) // In order to add the drops early for other mods (e.g. grave mods)
    public static void playerDieEvent(LivingDropsEvent event) {
        if (!ServerConfig.retainClawItems && event.getEntity() instanceof Player player && !player.level().getGameRules().getBoolean(GameRules.RULE_KEEPINVENTORY)) {
            SimpleContainer clawInventory = ClawInventoryData.getData(player).getContainer();
            for (int i = 0; i < ClawInventoryData.Slot.size(); i++) {
                ItemStack stack = clawInventory.getItem(i);

                if (!stack.isEmpty()) {
                    if (!EnchantmentHelper.has(stack, EnchantmentEffectComponents.PREVENT_EQUIPMENT_DROP)) {
                        event.getDrops().add(new ItemEntity(player.level(), player.getX(), player.getY(), player.getZ(), stack));
                        clawInventory.setItem(i, ItemStack.EMPTY);
                    }
                }
            }
        }
    }

Checked the GraveStone mod for some examples and it does hook into the LivingDropsEvent, so this modification is received and the claw tools are correctly stored in the grave for that mod.

Personally I think it is preferable for some items to be assigned to incorrect slots sometimes (and handle that gracefully, such as just finding the nearest empty slot or dropping it on the floor) rather than it just drop on the floor on death using a gravestone mod. Ideally, you make compat for every mod that does these sorts of things, but why not at least use NeoForge's events to be able to hook into the same path mods use to modify drops on death?

I understand there is only partial functionality when not using the event, but I don't understand how that is worse than no functionality at all. And you can always still add further compat regardless of whether you use LivingDropsEvent or not.

Hi. There are a few reasons why I opted out of doing this when porting to neoforge. I'll mention what they are, and then you are welcome to ask me to reconsider or something, in case you think I should change my approach to issues like this.
It mostly boils down to that the item layout can't be guaranteed. GraveStone Mod will take the list of item entities from the output, convert it to items, and then store it in lists assuming sizes of the inventories (36 normal slots, 4 armor slots, and 1 offhand slot). This is enough in 99% of all cases, but some mod might alter these sizes. There was this mod a while ago which made the inventory twice as big. That would mean that enchantments like curse of binding would be handled on the incorrect slots, and that could be bad for some people.
Additionally, modded inventories like curios does not always have a "linear" item storage. For example, if you were to remove some mods which added new curios slots (and not new items for these slots), these items would end up in incorrect slots if the only way of identifying where they were at was through a indexed list.
In addition to this, people using similar events on fabric, where I originally came from, just called the drop method directly, as there was no item drop collection by fabric api (I'm pretty sure this is the case, but don't quote me on it). This isn't that great of an argument, but it made the approach work worse on fabric, and I thought neoforge would be a similar situation.
Lastly (at least I can't remember any other reason at the moment), I want YiGD to act as well as possible as a backup system for all kinds of items and such. That includes when other mods decide that an item should be destroyed on death, I prefer to keep that information stored in a backup. That is not possible if I just read the list of item entities set to drop. I also handle when some items should be kept when respawning and such, although that would be easier to handle I guess, but perhaps not for all types of inventories, modded and vanilla.

My current approach to this issue is that when I find a mod which adds new inventory slots, which are not just extensions of the vanilla inventory, I directly add compat for these mods. Some people will not report such issues, and it might take a while before I get notified, but then the worst thing to happen is that the items drop on the ground next to the grave, or however you configure YiGD to do with the rest of the items. It might not be a solution where all cases are covered, but it could be worse.

Again please let me know your opinion based off of this, and if there's anything I can do (other than build the compat module for Dragon Survival). If you think there's room for improvement, feel free to repeat yourself

Alright I'm not sure I understood 100% what you meant, although I figured out a way to solve it I think.
I'm keeping the mixin partly because that's where it's located in the fabric versions (and that works), but also because I want to assure priority, so no other mod handles their item drops before YiGD can save it somewhere else. If that would cause some compatibility issue with some other mod I'll probably learn about it and fix it then, but as of now I don't really see a situation where that could happen.
Anyway, instead of generating the grave from the mixin, it's saved in cache, and generated from the lowest priority in the LivingDropsEvent event. I don't have a mod to test it with, as your mod is not released on 1.21 neoforge yet (as far as I can see), and I don't feel like building it just to test this. You're welcome to do so by just downloading an artifact from my github actions though.

Also in case you would still have opinions, do let me know about them.
Also I assume there isn't a maven set up for Dragon Survival is there? I'll probably just end up using curse maven once it's released if not.

The 1.21 version is still indev, but very close to release. I can provide a built jar for you if you want to test. There isn't a maven setup for it, yea.

Overall this seems like a fine way to move forward. Thanks for the support 😄

Sorry for the long wait. I've been heavily procrastinating uploading new releases of the mod for some reason unbeknownst to me, but now a new version has been released. Additionally, there's also a new event (LoadModCompatEvent) for more easily implementing/loading compat with yigd.
Sorry again for the long wait, and I hope this will work for you. Thank you for the suggestion anyway!