You can check by looking at the RetroArch's debug log and by running cat /proc/bus/input/devices.
Remembering your first RetroArch debug log, my guess is that RetroArch counts twice a mouse device as both /dev/input/mouseX and /dev/input/eventY. You can check this theory by adding a mouse (so you have 3 devices) and using indexes 0, 2 and 4 to see if each device is detected and working.
Okay. I can see that now, with access to the computer again. (Remember, it's in a different place than my desktop, that I use for posting.) Thanks!
Now I have the primary Mini PAC set in Keyboard Mode and I see that it recognizes the Mini PACs as devices, but also recognizes the devices on them separately. It looks like keyboard in the Mini PAC gets an event node. Interestingly, the Ultimarc SpinTrak (the spinner) gets Event 5, not 6. When I test with cat /dev/input/event6 I get input from the spinner and I don't with event5.
But this shows me that some of the devices are broken down into multiple devices and explains why something else is "in between" the trackball and the spinner.
As a side note, even though this is a built in function for RetroArch, I've now done what the manufacturer claims can't be done. Xtensions claims that, in D Input Mode, you can only have one mouse device, so you can have the trackball (somehow that always ends up as the one to take priority) but not the spinner in that mode. I'll be writing them about that!
When I have all my questions worked out, I'm going to either write up a few blog pages or make a few videos for others with the same issues. I'm hoping that they will use the so their other customers can get this working, too.