Long topic... where to start? 
In general: As mentioned, all rotations are basically intrinsic rotations, but they don't work exactly as you may expect. Basically a construction element keeps all information it needs to reconstruct the rotation from an empty quaternion. When rotating a construction element (while placing it), you basically just increment (or decrement) the particular rotation values (rotation around x, y and z axis).
When converting these euler angles to a quaternion, the rotation values will be applied in the order y, z, x, i.e. yaw, roll, pitch, or in other words, heading, attitude and bank (when thinking of an airplane).
However, since we're going to rework the construction system in the future anyway, we will check out if there is a more convenient way for the rotations 
From your screen shot it is not easy to appreciate angles, so I may be wrong, but the rotation around the beam Y axis does not look as it be precisely 45°.
Getting fully accurate angels is not that easy. There is always a loss in precision when it comes to the conversion of euler angles to quaternions, this is unavoidable. Especially since the game just uses floats, which have a limited precision (but even when using double values, there is always a precision loss when converting euler angles to quaternions). But usually the precision is sufficient, as long as we don't want to create some CAD software 
Precision is not optional: if you don't need it and it is there, it does no harm
It depends, at least when we're talking about precision in general. For example, the translation of every element has a limited precision (since we want to keep the amount of data the game has to store per element as low as possible). When it comes to the rotation, there is still some room for a higher precision (i.e. 0.5 degree steps), we just thought it wouldn't be necessary at all (that's why at least the stetr command does not accept values lower than 1).
Now, jMonkey (the framework RW is developed upon) comes with built-in support for them and I cannot think of a reason strong enough for NOT using it, as RW apparently does now.
Basically the JME implementation of euler-to-quaternion conversion is based on this: http://www.euclideanspace.com/…lerToQuaternion/index.htm
Nevertheless, RW mainly uses JME for rendering and scene management (and JME does an awesome job when it comes to these things). But everything that goes a little bit more into detail requires specific solutions (best example: water. Actually the RW water has absolutely nothing in common with the JME water, although JME offers great looking water "out-of-the-box", but that implementation isn't compatible with dynamic worlds, or more precisely, voxel based worlds).
When it comes to the translation or rotation of objects or constructions, we have to do our own math (basically a construction element isn't just a single object, it's baked into a mesh with all other contructions in the same chunks (same applies to objects, like furniture). When it's necessary to transform a single element (e.g. opening a door), the particular vertices are just rotated around a certain point (since the game doesn't know anything about the door except its offset in the vertex buffer).
Challenge
Achieving this is tricky when it's necessary to have a precise rotation. Getting appropriate screenshots is even more difficult, since it highly depends on the camera view (having a parallel projection would be more helpful in this case^^). However, here is a beam which should meet these requirements. It's necessary to use a rotation precision (setr) of 1 (indeed this is a situation where 0.5 degree steps would be helpful). To get exactly this angle, you have to experiment with the x and z rotation a little bit.
We will check out what's going on there!
