I'd also say, that this is the main problem.
It works like this:
The miner is working on a coin, while the pool already switched to another coin. The miner submits the done work to the pool and the pool answers: "Don't give me these results, they are no longer valid, because we are already working on another coin", throws it into the bin, and the submitted work is not counted for your REAL hashrate (the "pool-hashrate"). That explains the difference between what the mining-software shows and what the clevermining-website displays.
This isn't the case at CleverMining. When we switch to a new coin, all old work for previously mined coins is still valid and will be accepted (until there is a new block at these other coins which will obviously invalidate the work). This is the reason why you should never use --no-submit-stales at coin-switch pool. We do things the smart way and always accept work for previously mined coins. (if we didn't, rejected percentage would be an order of magnitude higher).
OK, if it works like you describe, why are there massive break-ins in the hashrate from time to time, which causes a really severe lowering of the overall hashrate?
On other pools, that don't switch, it doesn't occur. If all submitted work counts, a drop in hashrate should not even be the case, when the pool switches to the next coin.