I'm recording Inquisit data simultaneously with eeg via either Cedrus stimtracker or just homemade VCP device, and latencies in eeg marks are consistently larger, than in Inquisit data files - 200 ms for pictures, 345 ms for following keyboard response. It seems like this lag is growing during the trial and depends on scenario structure, but I cannot check it yet, and it doesn't vary between multiple runs and participants.

This alone isn't really a problem, since lags are constant between cases and I can recalibrate all my analyses, it's weird stuff about consistency: in inquisit data pictures show latency exactly as programmed in scenario and larger in eeg, but response times are reasonable in eeg and often outright impossibly tiny in inquisit data - to get 80ms response time in Stroop test you have to start motion before you see picture, but most participants score 100% of correct responses.
And no, don't try to say that it may be actual time - I triple-checked all publications I could find on this paradigm and sure that response time cannot drop significantly below 300ms without lowering correctness of response.
When I record inquisit session without eeg, response timing is the same, statistical checks show no significant differences and impossible times are still there.

Question is: where is this time actually lost and how can I know true response latency? Especially in case i don't have any sort of simultaneous record to evaluate this lag (and every simultaneous record will contain its own lags anyway).

Thanks for the code and data file. Quick question: Your trials are set up to only start recognizing responses 350 milliseconds into the trial.

<trial BBLT>
    / stimulustimes = [1 = BB_LT, Points, markBB]
    / validresponse = (32,37)
    / iscorrectresponse = [trial.BBLT.response == 37]
    / responsemessage = (32 , markpress1, 0)
    / responsemessage = (37 , markpress2, 0)
    / responsetime = 350
</trial>

i.e. a recorded latency of, say, 40 milliseconds would indicate a key press that occurred 390 milliseconds after the trial displayed its stimuli. Is that intentional? And if so, what's the reason for this set up? Note that this jibes well with the discrepancy you described (" latencies in eeg marks are consistently larger, than in Inquisit data files - 200 ms for pictures, 345 ms for following keyboard response"), in other words the time you send the stimulus onset marker ("markBB" in the above) trial is _not_ the point in time relative to which you've instructed the trial to measure response latency.

It was set to ignore too early reactions, since they have no sense in our particular case.
My colleague, who's working on egg, tested this, varying parameter, and it was sort of confirmed.
Basically, we were confused with what's said in manual - it's said, that responsetime only sets window to ignore responses, no word on resetting latency timer for ones accepted. Am I understanding that part correctly now?
And isn't it deprecated in Inq4 anyway? I reckon it was replaced with beginresponsetime.

/responsetime determines when the trial starts accepting responses. Latency is measured relative to that point in time. /responsetime as an attribute name is deprecated, but it of course still works for backward compatibility. Its replacement in Inquisit 4 and above is /beginresponsetime, its meaning and functionality is equivalent to /responsetime.

Hope this clarifies.

To add, if you wish to ignore early key presses yet _still_  measure latency from the start of the <trial>, you would use /isvalidresponse:

<trial BBLT>
    / stimulustimes = [0 = BB_LT, Points, markBB]
    / validresponse = (32,37)
    / isvalidresponse = [trial.BBLT.latency>=350]
    / iscorrectresponse = [trial.BBLT.response == 37]
    / responsemessage = (32 , markpress1, 0)
    / responsemessage = (37 , markpress2, 0)
</trial>