Note that this was accepted in the previous JIRA system, but seems to have vanished when the system was changed to this one:

Please read the above and look at the attached illustration.

In other rendering systems, a normal map can be reversed (negative scale in U) to match a reversed diffuse/albedo, and the tangents will still be rendered to reflect light in the correct direction (same direction as the unreversed texture; by inverting the U in the map).

In SL, if the normal map is reversed in either PBR or Blinn-Phong, the tangents are not corrected and now give reflection in the wrong direction; opposite to where the light is coming from. Please see the illustration attached to the JIRA report linked above.

Note that if the mesh itself is uploaded with the texture direction reversed in its UV map, then the tangents are rendered properly with light reflected in the expected direction, with the normal map being applied with positive scale, but on the pre-reversed UV map. So it would seem the ability to deal with the reversal is already present in the rendering process, but is not applied when the normal map is reversed manually.

This causes problems when creating and repurposing mesh and textures, which I am currently dealing with again, as I have many times:

When uploading mesh assets, many could be rotated in world to give an opposite version of them, and have their textures simply reversed if the normals were handled properly. As it is, either the mesh asset needs uploading twice (once with a reversed UV map) and subsequently double the download from SL's content servers when viewed, or the textures need uploading twice (with the normal map being manually inverted in U in the image editor). In either case, twice as much needs to be downloaded from SL's content servers to view the items as well as creating twice as much work to make them. It also makes the item harder to modify and repurpose because, again, separate textures need creating especially to cope with the reversal. The user cannot simply drop a standard normal map (and reverse it) on the rotated mesh.

All that is required (yes, I know it's not ever that simple) is a checkbox in the edit window to force 'proper' U-inversion when the normal map is negative scale. While it might seem it could be done automatically if the scale is negative, this could break existing content designed to work around the issue as above. It needs to be done deliberately, not automatically.