Hmm.  One obvious difference on my box:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
>>> time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015625)

So the "resolution" here is exactly 1/64.  If that's truly the resolution, then all the results I'll see are exactly representable as Python floats.

The "resolution" you see (0.015600099999999999) looks bizarre.  Not because of the trailing nines, but because 0.0156001 doesn't appear to have any natural hardware or software meaning in decimal or binary.

That said, I see we get the resolution from GetSystemTimeAdjustment.  I don't understand the Windows time functions, but also don't see anything in the MSDN docs to suggest that the results from GetSystemTimeAdjustment "should have" anything to do with the resolution of GetTickCount64.  But maybe they do - LOL ;-)

One other point:  we have lots of code of the form:

        info->resolution = timeIncrement * 1e-7;

That is, we multiply some integer type by a double _negative_ power of 10.  All such code is needlessly inaccurate:  no negative power of 10 is exactly representable as a double, so we suffer a rounding error in representing 1e-7, and then another rounding error from the multiplication.  It's trivial to reduce the grand total to one rounding error instead, by rewriting as:

        info->resolution = timeIncrement / 1e7;

But these rounding errors are too tiny to account for the difference between, e.g., 0.4990000000107102 and 0.5.

I don't conclude that we don't know what we're doing, but I bet we don't really understand what Windows is doing ;-)