Why bother pinning calculations to absolute currency values at all if they are guaranteed to be inaccurate as soon as the next market trade goes through? (And you even realized that by the time you finished writing your post!)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
Power costs are fixed. Earnings per MH/s are variable. You cannot derive an efficiency factor for e.g. X11 without knowing the current profitability of X11 mining. Profitability is known to (estimated by) the pool and would need to be communicated to the miner to calculate that factor. All I'm suggesting is to avoid this two way communication (or website scraping or whatever) and recalculation on the miner's side, just pass the two components (hashrate and cost to run) to the pool and let the pool figure out the rest.
I'm in no mood to discuss this with you, as you seem to be missing and/or ignoring what I consider to be obvious. So you can believe whatever it is that you choose to believe.
If something like this is implemented though, all engaged miners will lose a large portion of their profitability edge, and only pool operators and distracted miners will benefit.