This introduces another bug -- until the interrupt occurs, usb_cdcacm_get_pending() will falsely return 1, instead of 0. Probably what we want is to have usb_cdcacm_tx() check a new bit of state to see if a flush is still waiting, rather than overload the meaning of n_unsent_bytes in this way.

Incidentally, I don't know if you saw my source code comment in vcomDataTxCb() -- I tried to read the TX count from the appropriate BTABLE entry for the TX endpoint, rather than assuming that all bytes were flushed. But this broke the device: I couldn't send bytes. Do you know why?

Also, please use 4 space indents.