USB stack gives misleading indications when Polling Interval not 1

I am seeing some incorrect indications from the usb stack (XP SP2) when my
device indicates a Polling Interval of 2 on its isochronous endpoint:

My hardware has a high speed (not high bandwidth) iso In endpoint; it
generates fixed size 1000-byte packets at an interval very slightly over
250uS.
I have taken the isousb sample from the 3790 DDK, and adapted it to work
with my configuration.
Because of the data rate, it seemed sensible to increase the polling
interval on that endpoint so as to only poll every other microframe, so I
set a value of two.
I use the test app (rwiso) to read an amount of data from the device, and
the driver output is as follows:
IsoPacket[0].Length = 0x03E8 IsoPacket[0].Status = 0
IsoPacket[1].Length = 0x0000 IsoPacket[1].Status = 0
IsoPacket[2].Length = 0x03E8 IsoPacket[2].Status = 0
IsoPacket[3].Length = 0x0000 IsoPacket[3].Status = 0
IsoPacket[4].Length = 0x03E8 IsoPacket[4].Status = 0
IsoPacket[5].Length = 0x0000 IsoPacket[5].Status = 0
IsoPacket[6].Length = 0x03E8 IsoPacket[6].Status = 0
IsoPacket[7].Length = 0x0000 IsoPacket[7].Status = 0
IsoPacket[8].Length = 0x03E8 IsoPacket[8].Status = 0
IsoPacket[9].Length = 0x0000 IsoPacket[9].Status = 0
IsoPacket[10].Length = 0x03E8 IsoPacket[10].Status = 0
IsoPacket[11].Length = 0x0000 IsoPacket[11].Status = 0
IsoPacket[12].Length = 0x03E8 IsoPacket[12].Status = 0
IsoPacket[13].Length = 0x0000 IsoPacket[13].Status = 0
IsoPacket[14].Length = 0x03E8 IsoPacket[14].Status = 0
IsoPacket[15].Length = 0x0000 IsoPacket[15].Status = 0
IsoPacket[16].Length = 0x03E8 IsoPacket[16].Status = 0
IsoPacket[17].Length = 0x0000 IsoPacket[17].Status = 0
IsoPacket[18].Length = 0x03E8 IsoPacket[18].Status = 0
IsoPacket[19].Length = 0x0000 IsoPacket[19].Status = 0
IsoPacket[20].Length = 0x03E8 IsoPacket[20].Status = 0
IsoPacket[21].Length = 0x0000 IsoPacket[21].Status = 0
IsoPacket[22].Length = 0x03E8 IsoPacket[22].Status = 0
IsoPacket[23].Length = 0x0000 IsoPacket[23].Status = 0

So this suggests that every other packet is coming back zero-length.
However, when I look at the entire buffer from the user-space app there are
no gaps - every piece of data *is* there (and correct) from beginning to
end - all 24 packets. The return value from the read() call is 12*1000 yet
the whole buffer has in fact been written.
I've also used SnoopyPro to examine what the stack thinks the packets
contain, and diagrammatically (and very much simplified), this is what I'm
seeing (with "." indicating a zero-length packet):

According to stack Actually in buffer
0 1 2 3 0 1 2 3
.. 4 5 6 7
8 9 A B 8 9 A B
.. C D E F
0 1 2 3 0 1 2 3
etc

This is a problem to me because I will occasionally get genuine zero-length
packets (due to the data generation being asynchronous to the usb frames),
and I need to be able to detect them.
The USBD_SHORT_TRANSFER_OK flag is not set.

This only happens when the Polling Interval is 2; when it is set to 1 then
the behaviour is as expected (albeit interspersed with genuine zero-length
packets, generated by the h/w when it is polled but has no data available)
I'm running a free build XP SP2, but with checked versions of ntoskrnl, hal,
usbport.sys, usbccgp.sys and usbd.sys (also from an SP2 version).

Is it a bug in the usb stack?
There is a report of this kind of problem -
http://support.microsoft.com/?kbid=837371 - but although it is dated only a
few days ago, it seems to be saying that the issue is fixed in SP2; and I
have newer versions of all the files indicated (though why don't I have
usbccgp.sys - isn't that needed for composite devices??)
[I'm having trouble with my Win2K installation at the moment, so I've not
had a chance to compare].

In fact, as I repeat the test today to check my results (before hitting
"Send"), I'm *also* now seeing an additional effect: a packet with a length
of 1000, but contents all zero - but, again, without any loss of data -
where there *is* data in the buffer it is continous and valid (the data
stream contains a count to help spot discontinuities).
What with the results I was seeing yesterday plus this additional weirdness
I'm now seeing, I'm wondering if there are still issues with non-one values
of polling interval?

Anyone got any thoughts? Can anyone at MS confirm whether 837371 really is
fixed?
Thanks.