Hi Paul,
The config utility was originally just an excel spreadsheet. I've been improving it over the years, and while I accept it is not a brilliant piece of software, it gets the job done. It's written in Java using Processing and ControlP5 as a back end. They are good for quickly throwing together a program, but not great for well engineered software. In any case, in response to your points:
(1) Is no problem. Will add that
(5) I'm not sure why it is needed, but I can add that relatively easily. The go-to rate is changed via the AstroEQ config, not via EQMOD, so in order to change it and test again you'd need to go back to the start. I suppose I could have it go back to the config page again, but the whole EEPROM programming step needs to be done to make sure everything is uploaded, and at that point it makes sense to read the EEPROM again to be sure that what is in there is what you expect.
(3) Appears to be missing, so another one ticked off
(4) I'd made it smaller in this one because some people wanted the utility to fit on a 600px screen resolution. Making it expandable is an absolute pain in Processing, it really doesn't like resizing, but I seem to have got it doing it (albeit in a hacky way). Font size has been increased too.
(2) I'd rather not complicate things. When gear changing is enabled, the uStep mode for fast movements is always 1/8th of the number of usteps than the slow movements.
With regards to your other issues. When the IVal is reported as being too large, it is not that the CPU can't handle it (in fact at that point the step rate is very slow), but rather that the resolution is going to be so low that it is really not worth bothering. There are other technical reasons too - one of which is that with IVals much larger you end up very limited in what <1x speeds that can be done. For example if you try to do 0.1x (the slowest EQMOD will do), that ends up being a 10 times larger value - for an IVal of 1200, the speed value would be 12000 (but ends up being 24000 in some calculations). At 0.05x speed (the slowest AstroEQ guiding will do), the speed value is 24000 (48000 in some calculations), closing in on the maximum value an uint16_t can hold.
I haven't yet had a chance to properly look at why the goto speeds are not being picked up correctly. I will hopefully get a chance soon.