I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer. Yes, you can fix it by patching sgminer... but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available. That's a logic problem in nicehash, not in sgminer.
NiceHash will send authorization error and drop connection. You can see that if you check logs of network traffic (sniff it, if you don't believe). Beyond that, there is nothing in our power to do about it, but to get sg/cgminer fixed. NiceHash cannot refuse connection until it gets authorization request, where p= is specified as password. Until this event, NiceHash will of course keep connection alive.
EDIT: Could you point me in direction of fix for sgminer? Thanks.
By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less). In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented. The current system isn't fair for providers or miners. As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is). As a provider, there's no solid reasoning behind what bids will garner what hashrate. I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour! (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job. That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.
For each order, extranonce1 has to be changed. This cannot be done otherwise but to drop connection and force miner to reconnect. Once extranonce1 is changed, miner WILL have to change it's internal work that is being hashed, because extranonce1 is part of the work that is being hashed. There is no point in any kind of buffering you are referring to.
If any multipool actually implemented "real" proxifications to other pools like NiceHash is doing, it would hit same obstacle of extranonce bug in cgminer 3.7.2. And I really don't recall/haven't heard of any multipool not being compatible with cgminer 3.7.2. This makes me to believe, that no multipool is actually doing internal job delegation which you can observe with NiceHash service - or when slush's stratum proxy is used. They most likely use same extranonce1 numbers and can of course do "buffering" as you propose, because work for hashing does not change after doing reconnect.
NiceHash appends additional byte to extranonce1 which is taken from buyers pool. It cannot give own set of extranonces, because all work would be invalid on target pool in such case - it can only iterate from 0 to 255 (appended single byte), while the first part of extranonce1 (4 bytes) is equal to what was assigned by the buyers pool.