I'm reluctant to add that kind of complexity for just this one scenario. It's only the de-activate event that needs it. It's easy to add the sound to the activate event. We're doing that for the lever. The de-activate happens during tick(). So, either we need to pass something with a world object (probably the PanelTile) to every cell during the tick so this one cell can make a sound, or we could have the PanelTile trigger the sound when the button's tick() returns that it changed.

The former would be the cleaner approach and would help if a future IPanelCell implementation wants access to such things during the tick. The latter would a bit dirty, but quick with slightly less tick overhead.

performance + dirty vs bigger overhead
that's always a matter that has to be weighed up.
I think the tick performance should be as optimal as possible.
Maybe the onPlace method #27.
With a transfer value of the type PanelCellPos.

It is getting the PanelCellPos during the onBlockActivate. It could just save it to a field at that point and use it during the deactivate tick. We shouldn't need to sync this field, so the overhead would be negligible.

I suppose I could give them a voice. I chose not to because the IPanelCell doesn't have access to sound events during the tick, and I didn't want to change that for just this one thing, but silent buttons feel wrong.

I am currently thinking about how to design something like that. Maybe something like a state manager?
onStateChange, setState?
These could then even be automatically saved as nbt data. writeNBT/readNBT

Fixed in 1.16.5-1.6.0b