I was pondering this too when I made the change. The most likely cause for too many steps being requested is similar to negative steps being requested, which is a programmer not correctly verifying inputs before converting steps to a point. 

In order to maintain compatibility with SelectionMover.move, I put in logic that if the requested steps are negative, a warning is logged and this function returns the first available step in the document. This change to when steps > max steps applies the same ration as for negative steps making the API more consistent.

Thinking about the probable use-cases, I think null or undefined is a bad choice in every situation, as the only reason a null or undefined is returned is because the programmer was already lazy in checking their inputs... so they are not likely to check their outputs ;-). I would be happy to change both negative steps and exceed max document length into thrown exceptions however.

The choices are:
1. Throw an exception which will terminate the action (and hopefully teach the developer learns they shouldn't do that). This means attempting to move the cursor beyond the start of end of the document will throw an exception and never execute the operation.
2. Assume (as was done in SelectionMover, and is continued here) that requesting an invalid number of steps is mostly harmless, and return a "nearby valid position" instead. This choice would reduce the number of exceptions thrown overall, but would make tracking down things such as OT-related errors (e.g., incorrect lengths or starts added together) more difficult.

With those options written out, I think (1) is the best by far, as (2) allows the potential for data corruption to occur at different clients in the case of OT errors.

Would you be happy if I changed both the negative case and the steps > max steps to be thrown exceptions?