If you think about it, it actually makes some amount of sense that moving the mouse in a circle would result in your camera facing the same direction, but with a different Z axis rotation. Since this is usually undesirable, though, there's a reasonably simple solution. Before you compute ChangeinY from temp and deltaHoriz, multiply temp (your up vector) by the inverse of your current orientation.

I tried the Inverse trick. This seemed to make the slight z rotations worse.
I also tried to multiply temp by the Orientation, and that fixed the mouselook BUT re-introduced the gimble lock!
I.e. its perfect movement, unless I look straight down/up and the left/right action becomes a rotation around the y axis. (Also when I turn completely upside down)

So Im still rather stuck. Could there be anything else that would effect it? i.e. model view matrix, etc.

if you are getting undesired rotation on the z axis one thing you could do is create a quaternion from an axis angle pair, where the axis is z and the angle is that between the world up vector and your local up vector.
dividing your orientation quaternion by this should give you a new orientation to use which will have the correct up vector.

edit: please note I could be wrong, I haven't tried this its just a guess.

You can't both maintain a constant up vector and eliminate gimbal lock. The two things are contradictory.

In my game Rescue (feel free to look at and use my source code), I use the cursor keys to pitch and yaw, and A and D to roll. This allows the player to rotate the ship to any orientation easily. I'm also assuming that beginners might feel that this is too many controls, and for them, it's entirely reasonable to play the game only using the cursor keys. As you say, this means you can end up 'upside down' if you rotate in certain ways, but it doesn't really matter... after all, you're in space, there is no 'up'.

The roll keys are really just there so that players who care about such things can use them to roll the ship so that it 'feels' the right way up.

Also...

Lunatic Wrote:The setting of Z to 0 was to counter the strange increments and decrements to the Z axis that were happening when I was multiplying the Quaternians together.

This is just a numeric accuracy limitation, and it isn't something you should worry too much about. Especially, there's no need to clamp individual values to zero when they're not quite zero.

Instead, you can normalise the quaternion's length periodically to stop it from drifting too far out of range. Use ThemsAllTook's QuaternionNormalize() function for this purpose.