I read through the open issues and was surprised to see nothing directly addressing this. I know you're painfully aware of this issue too, Cpt. I made this topic to help consolidate findings on different aspects of this issue. I apologize if it's redundant.

Some modded models, liquids & particle effects have a bluish render when exposed to Colored Light. This issue is most prevalent in enclosed spaces away from natural sunlight, but some mods like ChickenBones' Microblocks render a noticeable blue even under the sun, under colored or vanilla light sources. GardenStuff's Flower Pots have a blue sheen on some of their faces. Tinkers' Construct liquid metals render a dark blue when closed off from sunlight and lit by any other source. Vanilla torches' particles are blue when sunlight is cut off (caving is the easiest means of verifying this). There are several more instances, but these are prime examples.

http://imgur.com/a/nMaJw#0 - here is a small album I compiled to demonstrate some of the quirks of the bug. I'll be posting more albums as I test things out.

some mods like ChickenBones' Microblocks render a noticeable blue even under the sun

Actually, this seems to happen with any block that uses CodeChickenLib.

Interesting... I suppose that's good to know

(By the way, I mean the CCL render code. Blocks that only use the Minecraft render code work fine, even if other blocks are messed up.)

I've often had problems myself when working with packed color values - because _int_s in Java are signed by default, the very first bit tends to get corrupted when doing bitwise operations. Working with long values and downcasting the result to an int did the trick.

Maybe something similar is going on here?

I don't think you should have bits near the signed portion of the integer. What kind of calculations are performing that make that a problem?

I had problems in this loop when &-ing the alpha channel from texture 1 onto texture 2.
Similarly, someone may be doing some bitwise stuff to a packed color value so that the sign bit - because of the different format used by CLC - could fall somewhere into blue.

It's just an idea that popped into my mind, could be stupid, could be worth investigating.

Odd. EnderStorage and Chicken Chunks render fine, so I'd never thought CCL was the culprit (I never tested Translocators). I also notice that if a modmaker has multiple mods, and if one mod has blue tinting, all their mods tend to as well. Jaquadro is a good example with Garden Stuff and Storage Drawers. MrTJP is an exception with Project:Red, where only a couple modules have blue tint issues but somehow the multiparts like wires and gates render fine.

Those are openGL values... You shouldn't be sending those to the tessellator to be interpreted as bit-packed light values... (I don't think you are)

Most of the issues come from "format 2" in the write up I posted a while ago. Note that these values are NOT synonymous with OpenGL's bit-packed color representations.

Vanilla: 
0000 0000 SSSS 0000 0000 0000 LLLL 0000
CLC: 
0000 0000 SSSS BBBB GGGG RRRR LLLL 0000

So.... the top bit shouldn't have ANY data in it at all... there is a very VERY small chance (but not zero) that extra bits inbetween SSSS and LLLL are being shifted to the signed bit position... but that seems incredibly unlikely.

If issues DO arrise, it's usually because users tried "averaging" or dividing light-values in their TESR's without concern for any other bits that might have slipped in the middle there. The write up tries to mention this.

Some documentation that explains on a technical level, why things turn blue:
https://gist.github.com/CptSpaceToaster/8b6dbd107e5fe44ab7b7