> Quote - .... So DS Camera space uses a LH axis set while DS world space uses a RH axis set - is that correct? The mists are beginning to clear! I'll expand on this in the next post...

Correct. Technically DS mirrors the scene along the camera axis before rendering. And because the camera is at the origin the scene gets mirrored along the z-axis.

Quote - I've been assuming that any old unit vector is interchangeable with a normal. Changing the sign of 1,2, or all 3 of the components of a unit vector will still give you a unit vector, and thus I assumed a valid normal - is this incorrect? (I realise that you'd need to change the signs of all 3 components to 'flip' the normal)

Of course a normal is nothing else than a unit vector. The only thing that makes it different from any other unit vector is the fact that it is perpendicular to a surface. The only thing to remember is that when using a normal to display e.g. dents is that when the normal is tilted right for one pixel, it should be tilted left for another pixel (on the other side of the dent). That property can easily be destroyed when manipulating normals. This is not a hard rule, however, it just might look weird, and for experimentation everything is allowed, of course.

Quote - For my tests I've been loading a single sphere primitive into the scene. I'd assumed that the brick preview renders were using a similar, if not identical, object and that the mapping would be the same or similar. Test renders that weren't totally black seemed to indicate that the mapping was similar enough.

In most cases it is similar enough, but not the same: in the illustration i connected the s-variable straight to the color of the output. As you can see, in the render the increasing s wraps around the sphere counterclockwise, in the preview-sphere it wraps around clockwise. Often not a problem, but should be kept in mind when dealing with shaders that depend on the direction of the s-parameter (like normal maps do).