I think SPIGOT-7617 being fixed makes this unnecessary

I'd like to add that this is inconsistent with how EntityExplodeEvent works. event.getEntity() returns the entity, TNT, Creeper, etc.

This used to work, I have a plugin that relied on it but am noticing it no longer works. There's no easy way to identify the "cause" of the explosion if the getBlock is always AIR. There's no indication if it was a bed, respawn anchor, etc. Maybe the change was intentional, but it's not ideal it can't tell me what the original block was. 

I believe you're describing intended behavior.

If you prime and explode TNT, the TNT entity and block goes away. If you want to prevent this, just cancel the interact event.

Why should this work differently with a bed?

Inside "net.minecraft.world.level.block.BlockBed#explodeBed" the block which is the bed is set to air before the explosion is actually created, keeping it from even being destroyed by the explosion and thus appear in the list of blocks passed to the event.

I moved the explosion to the beginning of the method, before any block is set to air and I also removed the code which set the block to air in the first place. I came up with the questions below which should be answered before a solution can be thought of.

• What should happen if the explosion (by chance) does not destroy the bed itself?
• What should happen if the bed (by chance) is dropped as an item after being destroyed?
• If we were to set the original block to air after the explosion was created, this would override any changes made in the "BlockExplodeEvent" event
• Because a bed consists of two blocks, this causes there to be two bed blocks in the list of blocks passed to the "BlockExplodeEvent" event, which might be confusing and problematic for some