Currently, perfectly chaining beam animations is impossible. They change their phase in a manner that has a very tiny error, which takes only a minute to ruin even slow-moving beams.
Obviously, this would cause issues when changing the rate of beam animations, since phase is calculated with (tick()%period)/period * math.pi*2 and changing the period even a tiny bit would dramatically alter the result of tick()%period therefore causing a jump to a random phase.
So, a “phase” property (editable and visible only with scripts) could be added to beams.
The phase property determines the phase in the animation.
When the animation function of the beam sets the phase, it sets it to ((tick()/period + offset) * math.pi*2)%period
When the phase is changed by anything other than the animation function, the offset of the phase is changed such that the animation function would produce the current phase.
When the TextureSpeed is changed, the function above which is usually triggered by the Changed event is instead triggered with the current phase as the goal phase.
I already use a script like this to control time of day, such that day lengths and day times can be altered without odd results.