It should. How does it look if you place a Unity default shader side by side with this?

I actually haven't checked if this is fixed or not, but I would guess this may be fixed in 0.33. Would be great if you could check it out :)

Beta 0.34 just released now, just so you know :)

This should be fixed in the coming version (Beta 0.34). In the meantime, here's a potential manual fix, if it's due to the same issue:

http://forum.unity3d.com/threads/222049-Shader-Forge-A-visual-node-based-shader-editor/page75?p=1626992&viewfull=1#post1626992

This has now been fixed in 0.34

This has been fixed in Beta 0.34

This has been fixed in Beta 0.34

Appreciate the assistance with the example code by the way! 
However, mind that lightmapping is not only a single lightmap decode.

For single lightmaps - yes, that's pretty much it.

But not for dual lightmaps, and not for directional lightmaps.
Dual lightmaps need to handle the blend between direct LM without RT lights, and direct RT lights without direct LM.
Directional lightmaps need to have a separate output for its light direction, which also brings forth a few design issues as well as implementation quirks.

In addition, it needs to handle HDR vs LDR, as well as all of this in deferred rendering in addition to forward rendering

Glad it worked out :)

It's as you predicted, due to it discarding as early as possible, which makes it stupid in cases like this.

The dependency system in SF is awful at the moment, so things like this can naively be fixed in two ways: Postpone the clipping until after all the node variables have been set (damaging the performance of the shader), or spend lots of time remaking the entire dependency system into something sensible.

Perhaps I can move it down for now, until I remake the system for something better