The staff doesn't clean up after itself if it leaves the base inventory of a player. This can leave the blocks in that state permanently if the player dies, leaves the server, or just drops the item and lets it decay.

Perhaps registering a slow-ticking global event that reverts these blocks on the transmuted list until the list is empty, and no player with a staff is nearby, that then unhooks itself when the list is empty?

So I was going to go with the suggestion of the slow ticking logic that will do the clean up, but the more I think about this the more I am thinking I don't want to do anything about this.
Basically the logic would be very involved:

• glacial staffs notifying world logic of blocks that they transmuted to ice/obsidian and saving it to their NBT as well
• glacial staffs notifying world logic that they transmuted blocks back to liquid and removing these from their NBT (because I still want the blocks to transmute very fast if player goes out of the range)
• world logic checking for chunks that are actually loaded when trying to transmute back
• world logic serializing/deserializing all the data between server runs

And basically all of this for what I feel wouldn't be happening that often and I don't feel like a few transmuted blocks here and there would be a huge issue. It's not like you can abuse this for a gain given that you can get both blocks easily using other mechanics. And even if someone was planning to use this to grief I can imagine a lot of other ways that are much easier.

I will leave this open for some time while I chew on that, but likely will just close and leave it working the way it is today.

That's fair.

I'm not exactly clear on the logic in forge's ChunkEvent.Unload. Can the mod instantly transmute all blocks back to their original state when handling this event? If it can, it doesn't matter what happened to the player/glacial staff that transmuted them in the first place.

Edit: It looks like all the event handlers run to completion before anything is written to disk, so it should work.

I'm trying to think up a data structure that would allow each glacial staff to only store a globally unique identifier and load their transmute list as a weak reference to a portion of the data structure of all transmuted blocks for that dimension, but the dimension-wide list would logically be indexed by chunk, for cleanup, which doesn't fit with how a glacial staff wants to store its list for fast access.

Actually I'm probably prematurely optimising for a larger set of transmuted blocks than is likely on most servers.

Don't get me wrong the logic is totally doable it just seems to be very involved for what it is trying to solve - occasionally a few blocks left as ice or obsidian. Well unless I am missing anything.

closing this one, not going to implement the additional logic described here.