Cubeir

I tested this issue again and it has been resolved in 1.21.110.26 Preview.
However, the choice of color is questionable, the color is much more saturated than before this bug was introduced.

If ray tracing is enabled while inside a world, it triggers another bug that makes the world glossy.

Either that must be fixed, or this issue, otherwise enabling ray tracing is a convoluted mess requiring multiple steps just to get it working right.

Affects 1.21.110.26 Preview

Resolved.

Added a resource pack to help demonstrate this issue.

The pack contains a client biome for pale garden, where only fog component present which is referencing a pale garden fog with bright yellow colors.

The pack clearly demonstrates that at least some the missing client biome data is NOT being inherited from vanilla defaults. Because as soon as you find a pale garden biome in-game you will notice grass colors are a green instead of grey (as defined by vanilla client biome, which is also included in the pack for reference).

This issue still affects the latest Preview (1.21.90.26) as of now.

This was resolved in the most recent previews.

Hopefully it won’t return once this issue is closed.

Respectfully, I beg to differ.
Because this absolutely is an issue, vanilla entities such as breeze should continue work as intended in all graphics mode, vanilla, deferred lighting, and ray traced.

It works correctly in the first two, but not the third, because it was never accounted for to begin with. An entity released almost a year ago to the vanilla game still doesn’t display correctly in all of its graphics modes

It is understandable mechanics of games change between updates
Or that graphics and sounds may not work the same between versions as you implied, but that has nothing to do with Texture UV animations being completely broken with ray tracing which is the root cause of this and several other issues.

So unless a broader report already exists that covers the issue in more general terms, I think this issue should remain open, as it definitely remains an unsolved issue.

Updating a block’s state (e.g. switching a vault block between active and inactive states constantly) should also be causing this if chunk updates were the trigger.

Redstone contraptions that move blocks do trigger this glitch, while block updates do not seem to.

If a block (other than air) is already placed, replacing it for instance via setblock command should not trigger this issue.

For now placing by hand is the most reliable way to reproduce this issue.

I haven't had the chance to test all blocks yet, but other plane-shaped geometries may also have this issue if point lights are enabled. As of the latest 1.21.70.20 Preview, to my knowledge, this issue only affects Glow Lichen.

I provided a global.json for point lights. It seems the other example pack attached had an invalid json for point lights which is likely why you couldn't experience the issue, I attached the corrected example file, check out

You can also use any resource pack that defines point lights for glow lichen and amethyst to test for this issue.

I tested again and found out Amethyst clusters now render correctly in 1.21.70.20 Preview, however Glow Lichen still renders incorrectly. Check out the following screenshot:

For resource pack authors:
A workaround is to revert to the non-double sided (regular) variant of the blockshape.
This can be done for some blocks.
But some others such as Berry Bushes, Cave Vines, Dripstone, and more, a single-sided variant of the geometry was never implemented, ** this issue will permanently affect ray tracing unless addressed by Mojang. 

If you have any information about more alternative block geometries that could be used to temporarily work around this issue, please feel free to add.

P.S. This isn't a real fix, as you're only reverting back to something that was never broken to begin with at the cost of missing out on non-mirrored cross-shaped textures.
Worst part is I speculate this will apply to many more blocks with future previews and makes looking at a good chunk of blocks.. unpleasant! 
Some block shapes (such as torch) already have single-sided rendering with ray tracing! which shows it is a possibility.

Related to MCPE-183631

I wanted to add some new information regarding this bug, while it is fixed, it still happens to animated textures that belong to an array in terrain_texture.json.
e.g.

    "sculk_catalyst_top": {
      "textures": [
        "textures/blocks/sculk_catalyst_top",
        "textures/blocks/sculk_catalyst_top_bloom"
      ]
    },

sculk catalyst top is not animated, and sculk catalyst bloom is an animated texture, unfortunately PBR textures can not be animated for sculk_catalyst_top_bloom due to it belonging to an array.
same bug applies to Shrieker, which is defined like this inside vanilla terrain texture:

    "sculk_shrieker_inner_top": {
      "textures": [
        "textures/blocks/sculk_shrieker_inner_top",
        "textures/blocks/sculk_shrieker_can_summon_inner_top"
      ]
    },

In other words, for blocks that have animated textures AND multiple states which can affect the texture, animated textures remain dysfunctional!