This would be better in a separate thread, however, I appreciate your frustration here.

If you can confirm my assumptions:-

So, in summary, 3-axis machine - a DIY conversion of a mill. 3 motors, driven by three stepper-drivers, driven by a KK01 BoB, which in turn is driven by, what we understand to be a legitimate UC100. Software : Mach3 and UCCNC with the same observed behaviour.

I don't recall what stepper drivers you are using, or your main stepper PSU.

Observered behaviour: Missing steps (to the point where an axis will halt completely) in a given direction. This impacts typically at any time one axis, but that axis can differ on different tests?
Can you confirm: When an axis freezes - can you jog another axis whilst frozen? (so, if holding cursor-up freezes on Y+/Y-... does pressing cursor-left/right allow X to move)? (my reasoning... under the failure condition, does this only affect one axis or are other axis not currently active/observed also affected)

How often does this problem present itself. Is this once-in a blue moon, or every time you go to the machine. Or somewhere in between?

Is there any other relationship you can describe - for example does the problem only occur if the spindle is running, or otherwise (this is feeding a question into system noise and shielding and grounding strategies).

Visually, according to CNC4YOU website - it looks as though (though not documented) there is a power LED top-right of the board - is that illuminated constantly in use (both in good and bad operation)?

That you are losing motion across different axis *tends* to agree with your analysis that its unlikely to be the individual stepper drivers, or even steppers. So if you're looking for a common-mode failure you'd be looking at the PC/Software, UC100, KK01 or Stepper PSU. Personally I'd rule out the software because you've tried both Mach3 and UCCNC with the same behaviour. I'm not 100% convinced, but close enough that I'd not investigate the PC at this time (although it's an easy test if you have a spare PC/laptop).

Now, under normal conditions your specific description of losing steps in one direction, but not the other, is really very interesting - because it should never happen. Forgive me if you understand this already, but the conventional step/direction interface which clearly does work (at least part of the time) requires that the "direction" signal is a binary "left" or "right", or whatever you chose to refer to. The "step" signal is a pulse that commands the move. So, whether you're traversing "left" or "right" - you're generating a pulse train on the step pin - if you lose the "direction" signal you simply risk moving in the wrong direction.

So, if I believe your observation, my initial thoughts are that your direction signal is interfering with your step signal. At this stage I'd be eyeballing the wiring around the KK01, making sure there are no strands bridging between terminals or debris on the board. If the UC100 was dismantle-able I'd be doing the same with that. That's the first check.

That conveniently ignored the observed behaviour that this can affect different axis. That's more challenging and less logical. At that stage I'd be really questioning whether the behaviour of the KK01 was what I expected, and - short of deducing it was U/S - I'd be examining if the power to the board is correct (trust me - there's no such thing as a digital world - everything is a balance of probability) - and it's possible that the board is semi-operating without power by scavenging through the signal lines. I've seen it happen, in fact there was an investigation on here that was sourced from a a similar-ish issue (the solution for that isn't relevant here!). So, as much as you say your KK01 is fed from USB - please check and re-check that you've configured the KK01 correctly for USB power - pins 1&2 on the header next tot the USB socket.

How confident are you at tinkering with electronics, and in particular Arduino etc - the is a great use for them to either inject a pulse-direction signal into the KK01 (isolating the UC100), or to monitor the pulse train from the UC100. 30 minutes of coding could get you significantly better understanding of the problem.

Sorry, more questions than answers at this time. Be methodical and we can get to an end-state here.