Doug, thanks for the comments, they are much appreciated.
I'm not sure I understand how the DCM drift corrections are affected at all by the scheme. The way I look at it, ignoring the patch, if the IMU were placed upside-down in an airframe and turned on (with accelerometer bias calibration removed), the IMU should show itself upside-down. If the IMU were then arbitrarily rotated, the IMU should properly show these rotations and the final orientation (i.e. its normal behavior). So, if I placed the IMU upside-down in an aircraft and I wanted it's orientation to be displayed right-side-up on a flight display, I would e.g. take the orientation reported by the IMU, offset the roll by 180deg, and then display this orientation. The patch basically does this: it adds a static offset to the angles, but only to the reported values (the DCM is untouched). (I don't believe these offsetted angles are fed back into the DCM or IMU anywhere; if so then my patch probably doesn't work as expected.)
I apologize if I've just completely missed your point...it's been a long day.
Still, would a better approach be to apply the orientation offsets at a lower level (assuming it wouldn't muck up the drift correction)? For example, a secondary, static DCM could be created from the relative angle offsets and this DCM could be applied to the raw accelerometer and gyro vectors. It seems, using this approach, the accelerometer offset calibration could be left in during ground start.
The approach you are taking is too simplistic. It would be an acceptable solution if you wanted to mount the IMU say 20 or 35 degees off the normal orientation, but will mess things up for many of the possible 90 degree rotations. The roll/pitch and yaw drift are corrected independantly using two separate reference vectors. If you rotate the IMU into a position where one of the reference vectors has little or no orthogonal component with the axis/axes you are trying to correct, then you have effectively suppressed the drift correction for that axis. It would be OK if you wanted to mount the IMU components up and with the gps connector to the right side for example, but would mess things up if you wanted to mount the IMU on its side. Similarly, you recognize the euler angle singularity at pitch=90, but handle it just as a "can't do it" case. Using a rotation matrix there is no singularity and it can be done, but it requires either for the rotation to be implemented within the IMU object or significant rework to the drift correction algorithm in DCM.
Orientation changes where you keep the components up but rotate the IMU in yaw are easy - just use an offset approach like you have done. Orientation changes which only shift the z axis a small amount can also be done with an offset approach, but the further the z axis is moved from vertical the more the roll/pitch drift correction will be compromised. Orientation changes with significant rotation of the z axis towards the horizontal plane require a better approach.
This is a good item for the to do list, but due to the critical nature of the DCM and IMU libraries, not something that will be implemented without thorough testing. I think the cleanest implementation would be to apply a rotation matrix to rotate the accelerometer and gyro vectors in the IMU object.