I spent quite a while trying to figure this out. I was able to track down the original Mac drivers for these. I could not run them, as I don't have any Macs or anything with an ADB port and they wouldn't do anything in an emulator without a mouse attached (and I was unable to trick them), so I disassembled them. The important thing from viewing the archive of Microspeed's website, was a note that the newer driver required a mouse with a newer/updated firmware. In the newer driver, I was able to identify the code that was sending the string of bytes that's found in the Linux driver. My trackball didn't respond to these at all, and would never tell me anything for the contents of register 1 (which I don't know if that's normal).
Looking at the older driver, and reading the help text embedded in it, I determined that all of the features of it could be accomplished using the output, along with software logic. I also think that the output is weird, but structured in a clever way so that its button presses would all look like a button 1 click (or a click lock, for the middle button) if the computer were ignoring any additional buttons.
There is also a strange behavior I noticed, which now makes sense: if you hold down the middle button, then press the left or right buttons, the second nibble of the first or second bytes returned will be 1 and movement is no longer sent. The help text mentioned a "signaling" mode, where you hold the middle button, then press either the left or right button 1-4 times, in order to trigger a macro.
I have not decided how I want to implement the logic in the adapter. It may not be worth doing the more complex logic to track if the middle button is held. I think my ideal solution would be to rewire the switches directly to the adapter and ignore the nonsense from the mouse. This would likely be more difficult, as I don't think the adapter can currently look for any buttons on other pins. But if successful, it would be more generally useful.