The need to modify tags within the game is increasing every update as more functionality is controlled by them.
Tags are registered after all registries have been frozen but before the JavaPlugin system has been initialized which requires, then,
hooking into it with our Lifecycle Event API. Tags are then reloaded on a /minecraft:reload. Tags can also be changed at runtime
with updating the client to these changes as simple as sending an update tags packet. For now, we will just focus on the
event for handling regisration, and focus on modifcatons at any time later.
There are at least 3 spots that plugins might want to hook into tag loading and I'm not sure which combination should have specific events.
There could be an event that is fired per tag per registry. The only context available in this event would be the specific tag key of the tag being loaded, and the elements in the tag (which can be tags themselves). This would provide the simplest way to add/remove either specific elements or nested tags from that tag, but you lose out on the context of what a nested tag itself might contain.
After all the tags for a specific registry are loaded, they are stored in a structure like Map<TagKey, Collection<TagOrResourceLocation>>.
Firing an event at this point would let plugins add/remove elements knowing the full context, but there is at least one thing they can't do
which is remove a specific element that is added via a nested tag.
After the tags have been "flattened", that is all nested tags have had their elements added directly to each tag, we have a
Map<TagKey, Collection<ResourceLocation>. An event here has full control over the exact final outcome of tag loading, but you
don't know what, if any, nested tags where used to create the final collection for the tags.
The registry API has 2 events, one fired for each "entry" being added to the registry, and another after all have been added which provides a mechanism to add entierly new entries. It may be desirable to keep some similarity to this system.