On a standard RGB tangent space normal map, red channel contains the vertical details, green channel contains horizontal details, and blue channel is technically used for Z coordinates but FS2_Open's normal mapping implementation ignores that entirely, and tangent space normal mapping in general does not really use it as far as I know.
FSO's shader implementation is built around DXT5nm style normal maps, as it was (at the time) the best alternative concerning quality and compression. That means the shaders read the alpha and green channels from a map with -normal tag.
This also means that you really need to move RED channel specifically to Alpha. If you switch the channels, the shaders start looking for vertical normals info from a channel that contains horizontal normals, and vice versa.
It is a matter of preference whether you then make the red and blue channels black, or copy the green channel contens to them, but you must pick one to achieve ideal compression results with DXT5.
I'm sure there are converters that can import a bluish-magenta normal map, allow you to simply select -DXT5nm option, and out comes a normal map that works correctly on FSO, but then you really need to know that your converter does it right.
Personally, I prefer to manually adjust the channels, save as PNG or TGA, then simply convert that as DXT5. It removes all doubt of the final outcome, and also allows you to use uncompressed (u8888 or TGA) formats if you so choose.
Using white as the flood colour for red and blue channels is sort of nonstandard solution. Technically, if you do the channel management correctly (red to alpha, green stays on place), then FSO would read this type of map correctly.
If you use u8888 or TGA files which are lossless formats, this will yield identical results to gray+alpha or green+alpha style normal maps.
However, I am unsure how that would affect the DXT5 compression algorithms If I recall right, the algorithm does some sort of comparisons between channels and thus there is some crossover - the contents of red and blue channels tend to affect the contents of green channel on the compressed image. There are two known ways to bypass this issue:
When red and blue are black, the difference between them and green is the same as the green channel's content.
When red and blue contain copy of green channel, difference is zero.
Both of these options result in ideal compression quality that does not cause any crossover interference between RGB channels.
However, when red and blue channels contain white, the difference between channels is sort of inverse of the green channel's content and I really don't know how this would affect the compression algorithm. And, well, better safe than sorry - staying with blackened red/blue channels or copies of green channel is a known solution for achieving the best quality.
Also, the pink maps are really ugly.
By the way, I don't know what you are trying to achieve by testing "different" types of normal maps.
The specification for what sort of normal maps FSO uses are fairly simple, and deviating from them to "fix" a model/mapping error by "tweaking" the map (ie. making it nonstandard), it's the same as coding broken web pages so that they can be viewed with a broken browser.
If there is a problem with model geometry/UV mapping causing mirroring issues, then I have no idea how to help and will gladly leave it for the more experienced model mappers and converters to handle at their convenience. But I can tell you that "fixing" such a problem in the map by reverse-breaking it is not a good solution.
The standard DXT5nm normal map with vertical normals on Alpha and horizontal normals on Green channel should work. If it doesn't work, something is wrong somewhere else; looking at the map beyond correct channel positioning will not yield any helpful results.
