FBX export places rotation on wrong axis
sikand

I don't know, if fbx ASCII changed from blender vers. 2.75 to 2.77 or 2.78, but it is not wrong to update.

Maybe you can repeat a test again with only the z-rotation:

I did the test this way:

New file, n-key to follow the rotation data

Before you rotate the cube, you have to decide, whether you want to rotate the cube with xyz-Euler-angles or quaternions. It will break the animation, if this setting is changed afterwards.
(I think the reason is, that keyframe interpolation is calculated, when the second keyframe in inserted and can't be done, when the rotation mode is changed afterwards)

So lets choose xyz-Euler-angles instead of quaternion wxyz for this test (the result should be the same: keyframes change at Channel: "R" and Channel: "Y"),
in object mode choose i-key and in keyframe-menu choose rotation (rotation data become yellow and a yellow keyframe is inserted at keyframe 0 in the keyframe editor),
go to another keyframe - 12 - for example, r-key followed by z-key, rotate the cube with a mouse-movement (z-axis rotation data should change),
hit i-key again and choose rotation in keyframe menu. moving the green mark in keyframe editor
should rotate the cube now, a green color indicates the "linear interpolated states" between the keyframes (maybe you can control it in the "dope sheet editor").

That the animation becomes broken, when the rotation mode is changed afterwards can be tested:
When now quaternions-wxyz is selected, moving the green mark does not move the cube anymore and no interpolated keyframes are exported to the ASCII fbx-file.
So go back to xyz-Euler-angles.  

Now Export to fbx ASCII 6.1 with -z forward and y up, only choose "armat" and (shift) "mesh", animation, all actions and default take selected, export..
Compare files with WinMerge or notepad++

Do you have any info about the "default Lcl Rotation" or the 4x4 posenode matrix ?

greetings testuser

update:
Rotation with bones:

New file, delete the cube, if necessary center 3d cursor with "shift C" and add a single bone, the bone can be handled as an object and be rotated in object mode, (what one usually won't do, when a mesh is rigged - as far as i understand).

In edit mode the head (at the bottom), the body and the tail (on top) can be selected. Selecting the tail and rotating over x axis changes the tails y and z position.
Global and local transform orientation is z-up. In "object data" switching between rest position and pose position makes no difference. Thus with the rotation in edit mode 
the rest position is changed, not the pose position. The corresponding changes in the fbx file can be found at "Lcl Rotation" (= default rotation, these values are also used as default values of the default take).

In pose mode you can see, that a bone has an own additional local coordinate system with the green y-axis always aligned to the bones body (change transform orientation to local in pose mode).
Perhaps this may be the reason for your bizarre rotation results ?

The global z-rotation is a bones local y-rotation (if the bone is aligned to blenders z-axis) and this is exported to x-rotation-data, when export-options are "-z forward and y-up"

When rotating in pose mode, you create a difference between rest and pose position (with ctrl A and "apply pose as rest pose" the pose can be converted to default rest pose again).

What i think is, that this local system of the bone is used for rotation, if a model is imported for example into a game engine like unity or a "OpenGL code project". Manually changing one of the values of a keyframe inside the fbx file (rotation channel 
of a bone) rotates the bone over the bones local axes. When a bone (together with the mesh) in pose mode is animated and rotated inside blender, this rotation uses the global coordinate system instead and blender calculates
the x,y and z-values for the bones local coordinate system. These values are displayed under transform-rotation in pose mode and are calculated for each keyframe, when blender does the keyframe interpolation.

If you want to rotate a bone for yourself, it may be necessary to do this calculation for your own - the question is how, because the angle of the bone may be relevant..