Randomness in shaders is a tough nut to crack. There’s no way to get truly random values, and the built-in “noise” value has apparently never been implemented in a useful way (it always returns 0.0, which is arguably technically correct, since the values it returns are supposed to average out to 0.0…).
The alternative is to generate pseudo-random numbers inside the shader, but this is computationally expensive and has performance vs quality (i.e., visible patterns/looping) tradeoffs, as well as GPU/driver-dependent quirks. For example, there’s a famous one-liner PRNG that relies on inconsistencies in fract-ing certain floating point values, but it falls apart on mobile GPUs.
Similarly, many of the common PRNGs you can find online fall apart (or get out of hand, computationally) when the seed value–usually FrameCount in our case, so it moves around each frame–gets too high, so you have to modulo the value to keep it in a usable range, but whenever it loops, you get a sort of “reset” back to the minimum value, which is often visually noticeable and is exacerbated by happening at consistent intervals (every 783 frames or whatever is hardcoded in the mod() function).
One option here may be to sample a robust noise LUT using a pseudo-random texture coordinate, so you get the visual benefit of random-on-random without having to generate both of them on each frame.
It should have something to do that source size is doubled horizontally with the new version.
Anyway, thanks for trying things out.