If a JSON block model specifies the rotation attribute, vanilla will generate baked quads with the vertices transposed correctly, but the quad's facing will be that of the quad before it was rotated. This allows a call to BakedModel.getQuads to return BakedQuads which do not have the requested facing, and causes the lighting engine in Sodium to render incorrect results as it depends on the baked quad's facing being correct in order to avoid unnecessary computation.

There are a few ways to approach this issue, each with varying amounts of invasiveness:

• Throw out the problematic optimization and ignore the baked quad's facing, which will hurt rendering performance. It also doesn't fix other mods which may try to use the quad's normal data which gets baked into chunk meshes (i.e. Iris)
• Hook into BakedQuad initialization and set a new facing based on the normal vector, computed by the quad's vertices, and overwrite what vanilla passed along... Should be safe, as vanilla is bugged by this as well in normal data.
• When rendering blocks, check whether the BakedQuad's facing matches the direction we just passed to BakedModel.getQuads, and if not, calculate new data with the "correct" facing. This makes the slow case a rarity, but still doesn't fix other things in the pipeline which depend on the BakedQuad having the right data in the first place.

A test case was provided by Layl#8888 on the Fabric Discord which reproduces this issue clearly.

Example of broken lighting
Example of broken block model

Issue is resolved in 0.6b1 and can be closed

Thinking over this issue, I personally do not see any situation where a rotation set to 0 giving a different result from no rotation specified at all is an intended feature rather than a bug. Maybe fix it in BakedQuad initialization with a conditional option for compatibility just in case?