Nvidia 1070, Win10
Bug reproduced in 2.81 Alpha (2019-10-06 14:05, hash 54a9649e2636), 2.80, 2.79b
Normal inputs on nodes are sometimes ignored, for example, when feeding a normal input a value from a combineXYZ or mixRGB node without inputs from other nodes.
Following file, created and saved in 2.81, demonstrates the bug:
Shader group in that file has four different pathways to alter/create the normals of the unmodified plane (which, as an unedited plane, has a normal of 0,0,1.)
A mixRGB node that mixes between the object's normals and an arbitrary color (topmost pathway) alters the normals for any mix factor. But a mixRGB node that mixes between 0,0,1 and an arbitrary color (second pathway) does not alter any normals-- the object continues to use its default normals. Even though those should give the exact same output.
A combineXYZ node without any inputs (third pathway) does not alter the normals, same as the second pathway.
Interestingly, a set of combineXYZ and separateXYZ nodes, set up to be fed from the object normals but to completely ignore them (fourth pathway), alters the normals. Again, easy enough to see that this and the third pathway (provided identical inputs) should give the same output.
The workaround, to create arbitrary normals in the material, is demonstrated: use the original normals, but jump through hoops to replace them component by component.
This is a bug that's maybe not a huge deal for the intended, not-very-typical use (although it is frustrating to figure out why Blender ignores arbitrary normals created in the material), and there is a workaround, but is suggestive of some weird architecture that could be involved in other bugs, so I think it'd be worth taking a look at.
(sorry, not sure how to prevent the automatic markup that's linking the hash to other issues.)