BB USB interrupt in: transfer length only increases

While looking at USB Bluetooth yesterday, a curious bug has surfaced. Commands are sent on the control endpoint; every command causes a status message on an interrupt IN endpoint. The length of the messages is variable. However, doing

SYS DeviceFS_CallDevice%, (1 << 31) + 2, usb_dev$, inpipe% TO ,,, r3%, r4%
transfer_length% = r3% - r4%
... input transfer_length% bytes...

the transfer length is the length of the longest message seen so far.

Bizarre, or what?

This is the 2011-05-25 version of RISC OS.

To be more specific: when a message hasn’t yet come in, or after I’ve read a message, r3% and r4% are equal. Once a message has come in, r4% decreases not by the length of the new message, but by the length of the longest message seen so far.