How the flaw can be encountered?

In my mod Aurora's Decorations, I tried to implement sign posts.

For reference:

The goal is simple: put a directional sign on a fence block, this can be achieved through the use of entities, but that can create some issues, or by making a custom block, which is what I chose.
The goal of the custom block is simple: mimic a fence block with less properties than the Vanilla block, but renders the same, and as a bonus, every registered fence blocks must have a sign post variant.
To achieve this it must mimics the look too, so I made use of FRAPI and BakedModels, the BakedModel is simple, use the blockstate of the fence it needs to mimic and its baked model, then emits those quads instead.

Now the trouble begins: fence blocks are a multipart model, which led to crashes when trying to emit the quads.

The emitBlockQuads is simple:

	@Override
	public void emitBlockQuads(BlockRenderView blockView, BlockState state, BlockPos pos, Supplier<Random> randomSupplier,
	                           RenderContext context) {
		if (state.getBlock() instanceof SignPostBlock signPostBlock) {
			((FabricBakedModel) this.wrapped).emitBlockQuads(blockView, signPostBlock.getFenceState(state), pos, randomSupplier, context);
		}
	}

I tell the model loader to use my baked model and I have the fence block model as a dependency, so I emit it and give it the proper fence block state instead of my block state. And you have to note that a multipart model will do block state comparison.

Due to an oversight in Indigo, it will crash due to missing properties in my block state.

Cause of the problem

The fence block model being a Vanilla model, it will use the fallbackConsumer, and here's the issue with it:
TerrainFallbackConsumer.java - line 87

As you can see, in the line final BlockState blockState = blockInfo.blockState;, it ignores entirely the block state I passed as parameter and use the block state of the block placed in-world!

and that's how the crash happens, making it use the block state passed as parameter could fix this issue entirely.

Notes

This flaw doesn't only affect this mod, actually it is one of the root cause of another defect in LambdaBetterGrass better snow feature, when using Canvas or Iris, due to materials being tied to block states, the snow model (which is emitted in a similar manner) will go through the fallback consumer, and loose all block state data, which means the renderer will then apply the same shaders as the rest of the block, which will lead to wavy snow. How is this relevant to the issue? Indium and Canvas used Indigo as a base of implementation, so this oversight has been copied over, and led to the same issues.

Fixing this in Indigo would prevent the crash encountered above, and prevent other implementations to copy over the issue.

I don't see what we can do about this without changing the API. The RenderContext has no way of knowing it was passed to a different block state.