I think this should be considered a bug for now and not a future feature.
The reason for it is that this change where you suddenly have to go from Vertex Colors to *"Face Corner + Byte Color" makes it impossible to Geometry Nodes to set Vertex Colors to "Byte Color" as output since it does not support "Byte Color" as output...only "Color" in .3.2.
So this change broke a all my stuff that I had built in Geometry nodes where I use Vertex Colors and want to Export as FBX in to Unreal Engine.
It worked fine before this possibility to tell Blender what type of Vertex Color it should use.

Strange...when running your file I get the same wrong values in all versions... but it is still wrong ;).
I can go as high as change to 0.441 in your file (break should be at 0.438) and it is still Yellow color instead of Orange.
Don't know if it is because I used fewer colors in my last test or if it was something else like the blend. file was created in 3.1.2 from start that made the differences between versions, because I could not get this wrong value yesterday on 3.1.2.
Can try to find the pattern to find the differences as well.

You can reproduce my reported bug from the steps using a default .blend file, so it should be very easy to reproduce...especially the first case.
I don't know when or if it has worked before. I have followed my steps from scratch both for case 1 and case 2 in all version from 2.79 and forward. Same result. It does not work!
So... just follow the steps in any version you like from 2.79 and forward and you should be able to reproduce the bugs.

I have tried all on my machine and it does not work with the .blend I sent to you earlier. Also tried on version v2.83.2.. but exactly the same result. First image gives a push of particles upwards... but it never continues in a circular shape... which would be the result if all 250 images was used.
Here is the total package of images I used for the test.
Hope you find a reason for this not working with me.

Hi,
Since it was not supported to pack image sequences according to Blender... but the file was so big... I still hope that all the images are there as well. If not, then shout and I'll add them.

Can confirm that it do this on 2.82 on my system as well. Sometimes in few seconds... sometimes direct, but it crashes. It doesn't matter if I use Halo, object or collections as enemies.

Sorry, but I'm not following your comment, but it could me that get it wrong here.
We have different instances of collections... but they are in the same view layer... both parent collection and the instances of collections.
I'll try to hide ALL in one layer...but that is not possible.
One layer, in my example above, has only the light/sun, Another layer (with all instances) has all the objects.
So, amount of View Layers doesn't matter. I don't have the parent in one layer and try to hide instances in the other.
It does not work to hide collection instances...no matter what you do or in what layer you have them, if you do not exclude them totally from render and that is not the purpose. I need them in the render, but not together with the background :).

Here is a small file with two layers.

1. I did a collection of a monkey, torus and cylinder. This is called Parent_Stuff
2. I did instances of that collection. They then got the name Parent_Stuff.001 to Parent_Stuff.006
3. Now I will have one layer with ONLY the sun (because I'm going to blur and add a lot of effects on it in the compositor). I do not want any other things on this layer. So, I select "Parent_Stuff" -> View_Layer -> Disable from View Layer in the layer called "Only_Sun"
4. I try to find similar things on the instances, but that option does not exist. Nor does they vanish when I select 3) on the "Parent_Stuff". I can't use "Globally deselect on render" because I want them to be in in the other layer.
5. In my first Layer "Parent_Stuff_On", I remove the sun... but let it still shine on the things using View_Layer -> Set Indirecr only. This works fine on all instances... and the parent...and the sun is gone as it is supposed to.