Merged mining doesn't cause instability unless the implementation is poor.  It can cause minor (<0.1%) drops in BTC due to added latency when preparing new work after a longpoll.  However, I'm specifically implementing this in a way where namecoin efficiency is sacrificed to let the pool run without skipping a beat even if namecoind is frozen/slow/crashed.  The only efficiency change will be work messages from the pool require ~50 bytes of extra data inside the coinbase.


UPDATE:  Phase 1 went well.  I've got the pool creating the bitcoin side of merged mining (coinbase message that includes the mm signal + namecoin block hash) while still successfully creating blocks.  Tomorrow I'll be working on building the NMC block with the MM headers included.  It's very likely this can be done by the weekend unless I run into unexpected problems.  Everything is in place so the entire namecoin side is running in a separate thread that will not block the primary pool/bitcoin threads.