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.