Hello! Author here (along with my inspiration benjaminbenben). This explanation is perfect. And yes, I think the TODO is to not render the custom cursor outside the viewport.
At least on Windows, i'm reasonably sure all the API does is tell the OS which image to render as cursor and the cursor is rendered entirely by the OS; meaning there's no control over whether the cursor is being rendered partially outside the viewport or not.
Solutions where the browser would have enough control would likely require rendering the cursor by itself, which would impart it noticable input latency.
That would be very expensive computationally, and as seen in the padlock, accompanied by latency and jitter.
It would also break the case where pages have legit uses for crosshair style cursors, or cursors that are rotated 180° in order to not overlay contents.
At least on Windows, i'm reasonably sure all the API does is tell the OS which image to render as cursor and the cursor is rendered entirely by the OS; meaning there's no control over whether the cursor is being rendered partially outside the viewport or not.
Solutions where the browser would have enough control would likely require rendering the cursor by itself, which would impart it noticable input latency.
Edit: Quick addition of a bounding box to the demo: https://wchristian.github.io/cursory-hack/