Blocks of giant mushrooms don't send block updates after growing

Confirmed for 1.13.1.

Blocks don't check if they are powered when placed, instead they sent block updates to all adjecent blocks. If a redstone component is updated by that, it checks wheather it was affected by the block update.
If you build a block update dector, like the one shown in the video, you can verify this.

An observer will still update, because they function differently (as they also update, when the blockstate changed).

Interesting. I kind of suspected that already, but I thought it only affected Redstone because the observer still triggered, so I didn't test further.

Okay, I've looked into the 1.13 (not 1.13.1) source code. So, it's kind of a tradition to name the MCP version in code analysis. Since MCP is not out for the current version, let's just say I used MCPConfig's srg file and applied the snapshot MCP names to it. Resulting code has 6,000 compilation errors (the decompilation is not completly wrong and mostly looks alright, so we can work with this to a certain degree).

To make sure we are talking about the same things, I'll put the "notch names" / obfuscated names in parenthesis.
There is a class called world.gen.feature.BigBrownMushroomFeature (obf: bqq). The method net.minecraft.world.gen.feature.BigBrownMushroomFeature.func_212245_a(IWorld, IChunkGenerator<? extends IChunkGenSettings>, Random, BlockPos, NoFeatureConfig) (obf: bqq.a(axt, bmp, java.util.Random, ej, brq)) is responsable for checking if the feature can be placed and if so, actually place it.
When placing a block, an internal method is called, namely net.minecraft.world.gen.feature.Feature.setBlockState(IWorld, BlockPos, IBlockState) (obf: bqf.a(axt, ej, bkt)).

net.minecraft.world.gen.feature.Feature.setBlockState

protected void setBlockState(IWorld iWorld, BlockPos blockPos, IBlockState iBlockState)
//protected void a(axt axt1, ej ej1, bkt bkt1)
{
    if (this.doBlockNotify) //this.aG
    {
        iWorld.setBlockState(blockPos, iBlockState, 3); //axt.a(ej1, bkt1, 3)
    }
    else
    {
        iWorld.setBlockState(blockPos, iBlockState, 2);  //axt.a(ej1, bkt1, 2)
    }
}

The integer at the end of the net.minecraft.world.IWorldWriter.setBlockState(BlockPos, IBlockState, int) (obf: aya.a(ej, bkt, int)) is a flag. 1 is "cause block updates", 2 is "send change to clients" (ored together it's 3, so 3 means do both).

The net.minecraft.world.gen.feature.Feature.doBlockNotify (obf: bqf.aG) field is set to false by the default constructor (as features are manly for the world generator and it makes sense that during the world generation, no block updates are sent).
Also noteworthy: There is only one instance of the BigBrownMushroom class which is stored in the constant (static final) field net.minecraft.world.gen.feature.Feature.BIG_BROWN_MUSHROOM (obf: bqf.U). Similary every feature has an instance stored in a static field.

Why this is differently for trees

This issue does not apply for trees. While they also do not cause block updates during world generation and the doBlockNotify (aG) field initialized with false in this static variable.
However, there are additonal calsses that are used for spawning a tree. net.minecraft.block.trees.AbstractTree (obf: bkc) is a class that is used for spawning a tree from a sapling. This class has the abstract method net.minecraft.block.trees.AbstractTree.getTreeFeature(Random) (obf: bkc.b(java.util.Random)) which is overwritten by classes for each particular tree (for example net.minecraft.block.trees.OakTree (obf: bkh)).

The implementation of this method will return a new instance of a TreeFeature with doBlockNotify (aG) set to true in the constructor. For that I'd suggest to also use static final fields for each tree class to avoid the creation of unnecessary objects.
Other than that, something similiar could be used for growing mushrooms.

Also, the implementation of the tree features calls the net.minecraft.world.IWorldWriter.setBlockState(BlockPos, IBlockState, int) (obf: aya.a(ej, bkt, int)) with a flag of 18 or 19 for some reason. The values that got ored together here are 2 and 16 (or 1, 2 and 16). 16 prevents neighbor reaction updates, like connecting fences or observer updates. This is the reason why MC-131014 is happening. I don't know if there is a reason why trees don't cause "state updates" during world generation, while other features do, but if this stays, at least the 19 flag, which is used when the doBlockNotify (aG) field is set to true, needs to be changed to 3 in order to fix this bug.

Confirmed for 18w43c.

Can't reproduce in 1.14

I can still reproduce this in 1.14 with the exact same steps. Did you accidentally resolve and comment on the wrong ticket?