Posted the suggested change here as an issue:
github.com/indilib/indi/issues/866 (And I'm about 50% done with the pull request)
The takeaway from reading through all the things that implement focuserinterface and the focuserinterface is that, 20 bits is all that's used aside from OnStep and OnFocus and to go through that, even at 1 step/millisecond and 20 bits is a 17 minute focus!
Also, everything communicates with the mount as if it's already a signed integer, fixing it to actually act like the documentation would be more issues than the reverse. (gcc, which is almost certainly the compiler used for INDI, will let you call printf(%d) with an unsigned integer, not give you a warning, and output it as a signed integer, which is part of why everything works for me. Actually, based on a quick look, so will Microsoft's compiler. There is only a single driver that actually treats it with the proper %u, and that's only for warnings not for output to the focuser.)
Internally, focuserinterface actually uses signed integers in it's calculations.
Most drivers also represent it internally as well, and I'd say that aside from one using an unsigned short (16-bit), and a few using uint32_t, most use signed doubles. Our current implementation relies alone on the FocuserInterface, and the INDI number variables are doubles. (Frankly I see a lot of unnecessary code in many many drivers. ie, lots of bounds checking, and because I looked at other drivers initially, I did that too.)
FocuserInterface also needs to have support for more than 1 focuser, but that's a separate issue. (And it should be pretty simple to handle, now that I've gone through things.) There's also the rotator interface, which can be used for OnStep.
----
As far as speed control: That isn't something that's going to matter for Absolute positioning.
A brief overview as to why that exists, and why I ignored it:
LX200 was designed when there were only DC motors, so you'd have a speed + time + direction. You can see this still reflected in
www.indilib.org/api/classINDI_1_1FocuserInterface.html with MoveFocuser, which gives you reasonable control over DC, and you REALLY need to be able to control the speed for fine vs coarse focusing. The methodology aside from computers was a hand controller with a few speeds and buttons for each direction.
This translates into the LX200 commands, which were the only ones for a while: In, Out, Halt, Fast, Slow, %speed
www.meade.com/support/LX200CommandSet.pdf Looking at the newer protocol specification,
www.meade.com/support/TelescopeProtocol_2010-10.pdf added some more like time for pulse and such.
However, OnStep uses steppers, with given positions. So instead of trying to use the above, there are more useful commands, where we can tell the focuser go to position X, and barring mechanical or electrical interference/problems it will. There's no need to go at 1mm go for 5 ms In/Out. When you can go: Make 2 steps. It is limited by the rate specified per axis (default is 8ms/step at least on Megas, probably lower on others) (Ok, it's actually defined as micrometers theoretically, along with a conversion factor between steps and physical motion. I personally just set that to 1 micrometer/step, as trying to calculate that on at least one of my setups was probably inaccurate and would require disassembly of the focuser (again). I'd say that's the best method, unless for some reason you know the proper physical conversion and want it to be stored like in the FITS header, I don't see much of a point.)
So I have left speed out of the implementation, because IMO it's useless for anything from within INDI. It might not be for a hand controller (I know some people have SHCs with focusing. Frankly there I'd use absolute.) Frankly, if allowed, I wouldn't have done anything with MoveFocuser, if it weren't a required function. (I used relative movement, ignoring speed, and using the duration as ticks) same as MoveRelFocuser). Relative moves update the Abs position in OnStep, so there's no issue.
So unless you have a reason to want to implement focuser speeds (and I honestly can't think of any good reason, unless you want compatibility with really old lx200 software, but that wouldn't be going through INDI) I would just ignore them completely.