To handle some race conditions and messages delivered with delay:

1. Tunnelbroker discovers token is invalid and queue message
2. Device uploads a new device token (handlers trying to do it on each app load)
3. BadDeviceToken is delivered.

In case 3 we just ignore the message because we're invalidating a different token (implemented in D12912).

Okay, this makes perfect sense to me, thanks for explaining