This sounds like a 3D scenario yes? The answer is not simple in that case. You are going about this correctly for position...rotation is another story.

Angular velocity is generally represented with a vector called omega. The direction of omega represents the axis of rotation and the magnitude represents the velocity of the rotation. You can think of omega as the time derivative of your rotation matrix R; however unlike position you can't simply multiply omega by your time step and add it to R. It's a bit trickier than that but it's not terrible. The formula for what you want to do is here:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CC0QFjAA&url=http%3A%2F%2Fwww.cs.cmu.edu%2F~baraff%2Fsigcourse%2Fnotesd1.pdf&ei=YgsHUvzCBOWh2gW13oHIAw&usg=AFQjCNHGXY6ZN2RYXF7f28loeidm1rOxZQ&sig2=8P7y8zCkm6aBEgpeuIS0vw&bvm=bv.50500085,d.aWc

at the bottom of page 8. This approach is going to lead you to another problem...how do you change omega to get rotations that correspond to the player's input? This requires applying forces, computing the torque, and then integrating the torque with the help of an inertia tensor to compute omega. Again, not hard but all the texts that explain how to do this require some familiarity with calculus and some patience.

I see, I misunderstood your question. While the method you are using to apply an angular velocity to your rotation isn't exactly "normal" it does get the job done. It doesn't extend well to doing things the "real" way with a physically derived angular velocity but you don't seem to be considered about that.

The 1st, 2nd and 3rd row of your orientation matrix are actually the local x, y and z axis of the player's local coordinate system specified in world space.

mtxRotation = | ux vx nz |
              | uy vy ny |
              | uz vz nz |

x-axis = [ux, ux, uz]
y-axis = [vx, vy, vz]
z-axis = [nx, ny, nz]

To adjust the players translation in a consistent way regardless of the current orientation:

vPosition += [ux, uy, uz] * vVelocity.x * fDeltaTime
vPosition += [vx, vy, vz] * vVelocity.y * fDeltaTime
vPosition += [nx, ny, nz] * vVelocity.z * fDeltaTime

Note that this is the same as:

vPosition += mtxRotation * vVelocity * fDeltaTime

In this scenario your velocity is always defined local to the players orientation. The x-component always corresponds to left-to-right motion, the y-component always corresponds to vertical motion and the z-component always corresponds to forward-to-back motion.

You can pre- and post-multiply by matrices on both sides without changing the validity of a matrix equation.

So to obtain Q2 from

Q' = Q2Q1

you would post-multiply by inverse(Q1) on both sides

Q' * Q1-1 = Q2 * Q1 * Q1-1

Q' * Q1-1 = Q2 * I = Q2

EDIT: So Q2 = Q' * inverse(Q1)

You can do the 2 multiplies on the right hand side in any order (without changing which matrices are on the left or right) since matrix multiplication is associative:

A * B * C = (A * B) * C = A * (B * C)

but not commutative (i.e. AB != BA in general).

EDIT2: Similarly for quaternions, you can pre- and post-multiply equations by a quaternion, and they are associative but not commutative.

If you are trying to find identities and operations for rotations/matrices in general then the following may be of use as well

(AB)-1= B-1A-1

If a matrix is orthonormal (all rows are perpendicular [orthogonal] to each other and normalised, as are the columns)

AT = A-1

where AT = transpose of A. 3x3 Rotation matrices are always orthonormal (as are 4x4 rotation matrices with no translation component).

Regardless of whether matrices are orthonormal (i.e. this is always true)

(AB)T = BTAT