Within PlayerBlockBreakEvents it is stated that PlayerBlockBreakEvents.BEFORE is called "before a block is broken" and "only called on the server, however updates are synced with the client". The issue is, only awaiting client-server sync still leaves render artifacts as the client calls world.setBlockState within ClientPlayerInteractionManager.breakBlock. So registering a callback to PlayerBlockBreakEvents.BEFORE with the intention of canceling the block break results in the block flickering on the client side since the client breaks it anyways and it isn't until syncing with the server afterwards that it is updated to the original value.

Unmodded client don't know which broken blocks server event will cancel. To fix this you need clientside mod. Even if fabric api will provide clientside before block break event, you still need sync system to provide client with information it needs to cancel block breaking, and this is not fabric-api's responsibility because it cannot predict which data need to be synchronized.

#3367
Is this what you need?

No, that event triggers after a successful block break, which is the opposite situation to the one in the issue ("canceling the block break").

No, that event triggers after a successful block break, which is the opposite situation to the one in the issue ("canceling the block break").

Indeed. I could do it myself with a mixin (I had previously), but I felt that the API should provide it

Clients should use AttackBlockCallback for this. The reason for not including this in the client block break api is explained here.