Thanks, Miguel. Sorry for going quiet for so long - I was off on an extended leave over December and am just now caught up.
The Windows Embedded Compact 7 Bluetooth protocol stack that we are using doesn't directly expose the ability to flush ACL buffers. An app note for an older version of the product mentions that the design of the stack doesn't permit it for a couple of reasons. WEC7 dropped some documentation, including that note, but I expect it to hold.
There is an extension mechanism available that we've used to send specific HCI commands to the radio to add features that that the stack doesn't support. The documentation implies that when implementing an extension to handle ACL packet flushing, the stack's L2CAP layer has to be bypassed and I'd have to implement an entire profile on top of HCI. The documentation is ambiguous enough that I might be reading that wrong, and maybe I can just force the flush myself, and have some out-of-band signaling to my application to indicate that the flush occurred, leaving L2CAP and the other profiles intact.
Later on this year, assuming there's time before we ship our product, I'll attempt to make an extension that flushes ACL packets on a connection handle, but I worry that the L2CAP layer in the protocol stack will not react well in the face of flushed packets. There are a number of edge cases to test, so that will be tricky. I'll contact Microsoft to see if they can offer guidance, but that's going to take a while, I think.
