When I Set Step rotation preferences to 22.5 degrees it increments by 22 degrees or something.

yes, it is incrementing by precisely 22 degrees, not 22.5.
If you set the increment at 22.5 and hit [ 45 times then you will get a perfectly vertical line corresponding to 990 degrees which is a multiple of 22.

similarly, it looks as if 7.5 will show the same or similar behaviour.

Only affects rotating by keyboard shortcuts ('[', ']') but not when 'Ctrl+dragging' the rotation handles with the mouse, which uses the same preference setting: «Constrain a rotation or skew to a multiple of the Rotation snap angle.»
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Transforms.html#Transforms-Mouse-SRS-RotatingSkewing>

(tested with 0.48+devel r9931 on OS X 10.5.8)

Reproduced with 0.46, 0.47, 0.48.x and current trunk r12188 - only affects the transformation via hard-coded keyboard shortcut.

Seems like a candidate for an 'easy-fix' to me (somewhere the decimal part of the "180/snaps" result gets lost or truncated to an integer value?) - @Johan, would you agree?

Related code:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/select-context.cpp#L888>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/select-context.cpp#L983>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/selection-chemistry.cpp#L1619>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/2geom/transforms.h#L212>

This is my first patch ever so please criticize me as much as you can (I'm serious on this). I was in doubt whether to make smallest change possible or to reorginize some of the code. I went with the first option. I hope with time I will find a balance between the amount of changes and general impact of the code.

thanks for the contribution!

I have tested your patch and it appears to work correctly, as expected. However, after looking at the data stored in the preferences.xml file, it appears that this variable is always stored as an integer, and so it would be reasonable to retrieve it that way as well. As far as the floating point behaviour of the calculated result is concerned, that can sometimes be imposed by using decimal points explicitly in an expression.
    A proposed patch of this type is attached, and appears to get the desired result. Would you have any objections if this alternative patch were used?

@Damjan - do you have any objections if we commit the alternative patch from comment 5, or do you have a specific reason for preferring the original patch from comment 4?
    - in either case you will be given credit for the fix, since you took the initiative to fix it and since your original proposal worked.

I have no objections, I had some difficulties in navigating the code so I somehow missed to check how the data is actually stored. It is actually good to see a better approach because with that I learned a better approach.

good to hear,
committed to bzr rev 12274.

The changes from r12274 merge cleanly into <lp:inkscape/0.48.x>, and fix the reported problem as expected.
The attached patch was tested successfully with 0.48.x r9963 on OS X 10.7.5.

Proposing to include the fix in 0.48.5.

Fix backported to lp:inkscape/0.48.x in revision 9994.