Any time a packet has to be retransmitted at the 802.11 layer (because no 802.11-layer Ack was received within the Ack window at the end of the packet transmission), the transmitting device may choose to send the retransmission at a lower (more robust) rate. So rates can change instantly from one packet to the next, so yes, on a millisecond time scale if not faster. Also note that rates are not necessarily symmetric. So the client may be using one rate for its transmissions to the AP, but the AP may be using a different rate for its transmissions to that particular client. If your GUI only reports one "speed" for the connection, is it reporting the rate this device is transmitting at, or rate the other device is transmitting to this device at?
There is no standard for whether software that reports the rate to the user should report the instantaneous rate of the last packet sent or received, or if it should apply some sort of averaging or hysteresis. I've seen quite a bit of variance here depending on the tool/OS/driver combination. And even if it reports the rate of, say, the last transmitted packet at the time the "GetRate()" (so to speak) API was called, how often does the user-level tool call that API? Once ever 10 seconds? Once a second? Many times a second?
I doubt anyone has enough data to say what is "typically" done. If you walk your way through the code for your favorite open source tool/OS/driver, then you could say how that combination behaves. Good luck finding out how closed-source tools/OSes/drivers behave in this respect.
I've definitely seen tool/OS/driver combinations that report the most recent receive rate, because it would often show a low number (which corresponded to the multicast rate) when the connection was basically idle. So when there was no real unicast traffic being sent or received, the software would be seeing all the multicast background chatter going by at the lower multicast rate, and report that as the speed of the connection. In that case, if you really wanted to see what speed the connection was capable of, you needed to be sending a lot of unicast traffic back and forth across the connection, so that you'd see the typically much higher unicast data rates get reported.