Minor Typically, when a mushroom block state updates, it will fire the BlockPhysicsEvent, which can be cancelled. The normal cancelling of this works proper for the BROWN_MUSHROOM_BLOCK, but when you get redstone involved with it, it seems to update it (server-side) even if the event is cancelled.
The reason this is an issue is because the state of blocks are continuing to be updated even after the event was cancelled if the source of it was redstone.
For the following explanation, I will be showcasing via videos. Please note that I have implemented textures on different mushroom block states for visual showcasing but these will not be needed to test as there will be console debugs.
As you can see in the video below titled "MushblockWorking", placing down 2 mushroom blocks next to each other AND cancelling the physics update works fine. If I don't cancel it, it wouldn't keep the block states since mushroom blocks will update each other when placed next to each other.
To prevent spam in this issue, I have attached some console debugs to a paste.
In this first paste, you will see the physics event fired for the placement of two mushroom blocks next to each other with the physics event being cancelled.
https://paste.md-5.net/kujayoramu.cs
Now, here is where the problem comes in, which is redstone.
If you refer to the video attached titled "Redstone Problem", you will see that by just placing down a piece of redstone on a mushroom block, it will update the block states of the blocks around the redstone, even when the physics event is fired AND cancelled, it doesn't actually cancel it properly. You can also see this in the paste linked directly below. The physics event is fired three times. The block at the location of "-112, 67, 213" at first has the "south" state set to true (which this should be maintained). If you look at the last debug set for the paste, it will show the same block with the "south" state set to false. This showing that even with the event cancelled, the block state is still being force updated.
https://paste.md-5.net/xuhedeniwu.cs
I have also gone ahead and created a demo plugin for this to be tested with. Please keep in mind that you will have to rely on the console output because I added the textures myself for the visual showcase.
[SPIGOT-6045] Mushroom Blocks ignore cancellation of physics update when redstone is involved
Black Hole
added a comment - Also related to SPIGOT-5390 Might be related: https://hub.spigotmc.org/jira/browse/SPIGOT-4256
There has been some change in the past to only call the physics event for the initial block which changed, and not for the affected blocks around it. So if you want to cancel updates of the blocks around a placed block, you will have to manually check those surrounding blocks and then cancel the event based on that. You seem to only cancel the event if the source block is a mushroom block. In your 'redstone problem video' you are placing redstone, so there will probably be a block physics update with type redstone. You need to check if there are mushroom blocks around and then cancel the event.
See also the updated Javadoc of the event: https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/block/BlockPhysicsEvent.html
Also regarding the events you observe: You have an original block physics update for the placed redstone which you don't log and don't cancel. This updates the mushroom blocks around it which change their state. As conequence of the mushroom block changing its state, a new block physics event is called for that mushroom block as well. Cancelling that block physics update won't actual revert the mushroom block to its previous state, because the mushroom block changing its state is not a consequence of the block physics event, but the other way around: You get a block physics event because the mushroom block's state changed (due to the uncancelled block physics event of the redstone block).
blablubbabc
added a comment - - edited Might be related: https://hub.spigotmc.org/jira/browse/SPIGOT-4256
There has been some change in the past to only call the physics event for the initial block which changed, and not for the affected blocks around it. So if you want to cancel updates of the blocks around a placed block, you will have to manually check those surrounding blocks and then cancel the event based on that. You seem to only cancel the event if the source block is a mushroom block. In your 'redstone problem video' you are placing redstone, so there will probably be a block physics update with type redstone. You need to check if there are mushroom blocks around and then cancel the event.
See also the updated Javadoc of the event: https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/block/BlockPhysicsEvent.html
Also regarding the events you observe: You have an original block physics update for the placed redstone which you don't log and don't cancel. This updates the mushroom blocks around it which change their state. As conequence of the mushroom block changing its state, a new block physics event is called for that mushroom block as well. Cancelling that block physics update won't actual revert the mushroom block to its previous state, because the mushroom block changing its state is not a consequence of the block physics event, but the other way around: You get a block physics event because the mushroom block's state changed (due to the uncancelled block physics event of the redstone block). 
I think you can close this issue since parts of this behaviour are clientsided: https://github.com/PaperMC/Paper/issues/2649#issuecomment-703660457