There's no diagram I can find in the API Message Sequence section which documents when this event occurs. However just thinking about the sequence of radio events which make up a scan/scan response, the response is sent right after the request is received right down in the stack, I can't see any possibility at all that it sends out an event and then delays for the response data to be set, it wouldn't work. Also, all the functions I'm aware of in the API set data for the next radio event, not the current one, and all the messages are prepared in advance before the radio is turned on.
So there's no documentation which I can find which specifies it, however I can think of no way in which the scan request report would arrive until after the radio event nor that you could set the scan response data for the current advertising event.
I assume you're trying to do something like wait for a scan request to come in before setting the response data to something 'current' instead of keeping the scan response data constantly up-to-date even when nobody is asking for it, for efficiency reasons. If you are, perhaps you could set the scan data to a 'not up to date' marker value in general then, when you receive a scan request report, start keeping it up to date for the next few advertising packets, so the client picks up the data on its next scan. After a short while go back to the default 'not up to date' marker value. The client will have to see a couple of advertising packets to get the data, but that's probably ok.
I'm fairly sure this is correct. You have 150 microseconds from the reception of the scan request until the scan response has to be out. There is not enough time to signal this to the app, potentially waking it up and switching contexts twice - in addition to copying data to the transmit buffer the radio uses.
The intention of the event is to signal that a scan happened, not to update the data before it goes out. New adv/scan data is only pulled between advertising events too, as you mention.
