MSP430F5529: USB10 Errata on Linux Hosts

I read through the posts at https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/835399 and had similar questions about the USB10 Errata item at http://www.ti.com/lit/er/slaz314ac/slaz314ac.pdf, also can provide more detail based on what I've noticed in my scenario.

We've had a failure which has been reported on field units in which a device drops off the USB bus during operation.  The MSP430 is connected internally to a device running Linux kernel 4.x and 5.x, and we've seen in both kernel environments. Software is polling for a HID report descriptor approximately once per second when the error occurs.  Since the USB connection is internal to the end device, the customer needs to reboot in order to resolve. We've noticed this problem appears to occur more frequently on specific silicon for reasons not understood.

I've noticed I can easily reproduce the problems associated with the USB10 errata on any hardware (including a TI MSP-EXP430F5529 development board/H7_Mouse example) in a Linux environment if I use https://github.com/DIGImend/usbhid-dump in a script which loops on the vid/pid combination. 

#!/bin/bash
set -e
vidpid="2047:0309"
while [ 1 ]; do
    ./usbhid-dump --model=${vidpid}
done

The device drops off the bus consistently in <10 minutes of testing in this scenario, and I can see the device spewing data on a USB analyzer trace.  Every time I've caught the issue thus far it's been on a SET_IDLE Request. Here's an example capture from the analyzer of the failure (when running H7_Mouse TI reference example on an MSP-EXP430F5529 development board):

Here's the normal successful handling of SET_IDLE:

Making the one line change to include the USB10 errata workaround with #define USB10_WORKAROUND 1 in usbIsr.c resolves the issues with the usbhid-dump script and makes it so the script can run indefinitely without the device dropping off the bus (I've gone as long as several days and have never seen a failure.)

The quote from the errata document is:

This workaround is reliable and effective. However, as a side effect, it results in the creation of orphan tokens on the USB interface. Although the workaround is field-tested, and no problems have been reported with these orphan packets, it is recommended to use the workaround only if the errata behavior is problematic for the application in question.

We haven't seen any drawbacks of the workaround based on very limited testing thus far.  I'm wondering if you can provide any more information about the number of times this workaround has been "field tested" and in what scenarios?  For instance, do you know if it has been deployed on devices which are regularly or permanently connected to Linux hosts? 

I've captured new USB traces after the workaround and don't see any obvoius "orphan packets" or "orphan tokens".  Can you add any detail about what I should see on the USB interface when the orphan packets or orphan tokens are sent?  Will these occur on every SETUP packet? Or only on SETUP packets when the CRC timing issue would have previously occurred instead?

Thanks for any feedback you can provide.