Right... code is surprisingly easy to follow considering it involves 3D stuff...
Doesn't the normal vector just contain three (x/y/z) values though? While that does give you part of the story needed for the orientation, I suspect it misses some as well.
For instance, a normal vector pointing up would just be 0/1/0... but an orientation vector would have the pitch at 90 deg up (personally I don't know how they encode it, but probably +1), while bank and heading ... well, you can't really tell what that is from an xyz vector.
It seems to me there is an information tradeoff converting between the two; XYZ vectors store length, while orientation vectors store the banking detail... so you pretty much need two XYZ vectors to fix orientation, rather than just one.
Sometimes I think of it a bit like a skewer... if you poke a stick through the Pyro in the direction of the normal, you fix which way it's facing - but you can still spin the Pyro around on the skewer because the normal doesn't fix that part of the movement.
However, if you poke another one through at right angles, you can't turn it at all because you now have an exact orientation.
A bit weird, but it makes sense to me.
It's probably stuff you already know, though, since you've touched 3D and I haven't...
But I still get the 'we need more information' feeling from this.
What you COULD do, of course, is derive a kind of 'default' which-way-is-up vector from the cube, by perhaps the difference between the standard 'top edge' and the centre of the face (only a suggestion, as that involves more than a few averages and there are probably more efficient ways to derive such a vector). If you did this for the source cube and the destination cube, then I guess you could figure out the banking value for the source and set it in the destination, relative to that 'up' vector... but it wouldn't give the level designer a very good idea what would happen unless they knew how orientation was determined.