Mathematically those two shaders do the same (except they have a different freq), because (wave sin .5 .5 0.5 0.25) == 1 - (wave sin .5 .5 0 0.25), so if you call the value of (wave sin .5 .5 0 0.25) alpha, then the final color is crystal1.jpg * alpha + crystal2.jpg * (1-alpha). (Ok, my shader computes crystal1.jpg * (1-alpha) + crystal2.jpg * alpha...)
I think the issue that Spork is talking about is that the light emmited from the crystal texture doesn't match the color of the texture. This can be modified by the q3map_lightimage texture, the emmited light will have the (average) color of that texture. Unfortunately the color is compiled into the static lightmap, so changing the texture color at runtime does NOT work.
The only (clumsy) ways to work around this are dynamic lights, which are computed at runtime, but are more limited (e.g. no shadows), or to add the illumination in a shader stage on the surrounding environment that toggles at the same frequency as the crystal.