A client might be too busy to process any more work, so sends UNSUBSCRIBE to turn the flow off.
Alternatively, the client may be unaware that a backlog of messages exists and sends UNSUBSCRIBE.
There are at lesat three possible options:
1. The server delays sending the UNSUBACK until the backlog is cleared
2. Send the UNSUBACK and then send the messages
3. Send the UNSUBACK and then purge the messages
The client's last defense should it not want the messages is to disconnect and reconnect with cleanSession set to (1)
Hmmm...
In 2, the client received messages for a topic which it potentially thinks it has unsubscribed from. I can see that creating a lot of interesting head scratching when debugging a problem.
In 1, this stops a broker being able to immediately return a packet, and means it has to maintain a bit state, I suspect. It's also rather hard to define 'backlog', especially if one's internal design is a non blocking queue of some sort - no action can be taken based on an observation (a sort of Heisenberg-like thing, eg checking isEmpty then doing something. Think of the problem of incrementing a volatile int field in java).
3 would be my preference. It does not necessarily require a purge... It does fit nicely with the client's expectations.
However, we could leave the door open to 1 and 3. They're indistinguishable to the client.