Not sure about the coordinates being wrong, but in any case, PointToClient() creates garbage. And you will be calling this once every update.
http://stackoverflow.com/questions/13750394/garbage-free-client-coordinates

So in the end, I used interop:

[StructLayout(LayoutKind.Sequential)]
public struct POINT
{
public int X;
public int Y;

public POINT(int x, int y)
{
this.X = x;
this.Y = y;
}
}

[DllImport("user32.dll")]
static extern bool GetCursorPos(out POINT lpPoint);

[DllImport("user32.dll", SetLastError = true)]
public static extern int MapWindowPoints(IntPtr hwndFrom, IntPtr hwndTo, ref POINT lpPoints, [MarshalAs(UnmanagedType.U4)] int cPoints);

Thanks for the report, indeed, the code behind PointToClient is bad. Will try to see if I can fix the coordinates problem

Related question: Is there a reason why the toolkit Mouse position returns floats between 0 and 1? Wouldn't it be easier to just return the cursor position as is? That way the user wont need to multiply the floats back to correct x/y values?

I think this is a relative layout, and will help you when f.e. the elements size changes. 0.5 will still be center.

I realize that, but many other high-level libraries do it in this way. I assume for the majority it would be used as just getting straight x/y positions.

This should be fixed by latest commit. Concerning position in the range [0, 1], well, it is a convention. I found more practical to use [0, 1] as it directly maps to a texcoord and can be more friendly to different screen ratio.