1. Scantime defines upper boundary for scanning current work. Once GW gets data from pool, miner starts working on it for duration of scantime or until new block is announced by some pool. What happens is pool, especially local server (solo mining), accepts transactions after GW is complete? Does it informs miner about the change? What happens if miner finds valid hash for work which does not include mentioned transactions accepted by local server? Does valid hash becomes stale, e.g. upon miner submitting it to local server, hash is rejected? What are the negative consequences of using 30 seconds or less for scantime, and what becomes improved by reducing time?
When you're talking about localhost, you probably want to set scantime as low as possible to get the best benefit for the Bitcoin network. Pool mining is different, and usually the pool tells you how long to work on the job.
2. If there was no data change on pool since last GW, e.g. new GW gets same data as previous one, does it mean miner will start over or it will continue where it stopped (nonce), e.g. ignore data received by new GW?
Actually, this might very well be a bug.
3. Queuing less data than default (1) results in less stales and destroyed works, but it results in more requests per time sent to pool?
There is no harm to higher or lower scantime, so long as your bitcoind supports long polling to notify of new blocks. As of 0.7.1, it doesn't. More requests to localhost shouldn't hurt, except for the possible bug in (2).
4. Why miner does not switch to new block as soon as local server detects it? I'm solo mining without LP and looking at "Current number of blocks", which goes up at certain moment but miner does not changes block it's working on for < or = scantime seconds. Does it mean all those seconds miner is actualy working on previous block, which would result in hash becoming rejected if submitted?
If your bitcoind doesn't support long polling, yes.
In short = if I'm mining solo without LP and want to reduce number of stales (rejected), should I set queue=0 and scantime=few seconds?
In theory, yes. If the bug in (2) exists, it's a tradeoff.
