Yes, a revamp of the guider UI has been on my plate for quite a while. Hopefully it will get done in the next few months. Until that happens, though, let me try to describe what is going on.
Guiding can be split into (a) estimating the current error--how far and which direction the scope has moved from its target position in the sky, and (b) generating and producing a correction pulse.
SEP MultiStar is used for "a". I believe you are more concerned with "b", which is described below.
We send correction pulses to RA and DEC motors, so the scheme needs to understand what those motors do. Calibration is the process that measures, for each motor, how far "the target moves" when that motor is pulsed for N milliseconds, and in which direction it moves. This is complicated by backlash, but let's ignore that for now, and also assume calibration is "good enough".
So, given we have estimates for the RA and DEC directions in image space, and for RA and DEC's "arc-seconds of movement per millisecond of pulse" we can apply a control algorithm to correct the guiding error.
[Please forgive me if I'm over-explaining something you already know below, just wanted to be as clear as possible.]
Say we measured 2 arc-seconds error West in the RA direction, and 100ms pulses --> 1 arc-second of movement. A full RA correction pulse might be 200 ms East. Of course, it's not a good idea to full correct the pulse, so there's a gain associate with that, and if the gain is 0.6, then the correction pulse would be 0.6*200=120ms. That's a basic proportional control. That's what's going on with DEC and RA guiding (when not using GPG), with the exception that instead of entering 0.6 or whatever, you control the proportional gain by changing the values of the "Proportional Gain" row in the table on the "Control" sub-tab on the lower right of the Guider tab, where the RA and DEC values default to 133. Increasing the value (above 133) increases the proportional gain.
Why 133 you ask? Not sure, this pre-dates my involvement in the project, but I believe that 133 means "provide 133ms of pulse for a 1 arc-second error". That is, it is NOT using any calibrated measure of your mount. So, if your mount required 266ms/arc-second, then the effective proportional gain is 0.5. There is also a min-pulse field (e.g. don't send any pulses lower than, e.g. 30ms) which implements a type of hysteresis, and a max-pulse field which is a type of protecting for things going out-of-whack on a bad measurement. [BTW, there is also an Integrated gain implemented (defaulting to 0)--I haven't been able to improve my guiding performance when using it.]. That's it (if you're not using GPG). Thus, this guiding scheme does NOT use the calibrated "arc-seconds of movement per millisecond of pulse" values, but rather relies on the user to enter the appropriate numbers. It does use the calibrated directions for RA and DEC, of course.
If you are have enabled GPG guiding (which only applies to RA), then the situation is a bit better. The calibration measurements are used, and the gains are input in a traditional 0.0 -> 1.0 way. Ignore the "Proportional Gain" and "Minimum Pulse" fields in the RA column of the "control sub-tab", and instead use the settings in the Guider tab's Options --> GPG RA Guider menu. There you will find a traditional control gain (which does use the calibrated movement value) and minimum move value (now in arc-seconds). You also get a prediction gain, as the GPG scheme is predicting what the next error value will be and preemptively correcting for it. It's basically that, but slightly more complicated, see the code in: invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L341
BTW, I'm happy to take concrete suggestions for improvements and, even better, work with you and provide you with custom versions of Ekos you could evaluate and provide feedback for. However, this latter interaction would require that you compile Kstars from source (cloning and git pulling from a forked repo of mine).