UCCNC versus GCode Settings

So, does the (VCarve created) GCode take precedence at run time, or do other settings in UCCNC come into play that may conflict with the GCode?

The g-code will take precedence, and should override any settings in UCCNC, provided those setting are actually in the g-code.
Most g-codes are modal, and once used, remain in affect until another g-code changes them, or you change them when the g-code is not running.

This is the only reason, I'm guessing, for perfectly good GCode to be ignored and the spindle to go off on a weird path, ruining the material being milled (my earlier post "Mind of It's Own?)

This should not happen. If you see this happen, Feedhold the machine, or just try to watch, the DRO positions, and see if the DRO shows the machine where it's supposed to be according to the g-code, or somewhere else.

If the DRO's are showing the actual position, then the problem is with your g-code. If the machine is somewhere other then where the DRO's say it is, then the machine has lost position for some reason.

I am not clear whether the problem is a defective UC-100 USB controller,

I doubt that the UC100 is the issue, but I could be wrong. If the UC100 were defective, it most likely wouldn't work at all. I've never heard of any motion controller, for any software, cause the machine to move in ways other than the g-code is telling it.

Does the toolpath look correct when you load it into UCCNC?

Gerry, Can't think of a reason it would NOT be reliable, but because I suspected the GCode being faulty, ran it through a good visual test program, "CAMotics". It showed the tool and toolpaths running perfectly, all the way to completion. So, even though all x, y, and z movements go smoothly in jog mode, I like to blame someone/something other than myself, so I'm going to say it's the extreme sensitivity of the machine while running GCode. If I learn differently (being like a dog unwilling to give up a bone) I'll post new findings.