You can also take the plunge into msp timing objects. Definitely recommended if you're interested in accuracy. Phasor~ and rate~ would be two objects useful for your current situation. As a pre-MSP Max user, I've found it helpful to build a metro-like abstraction based on phasor~.
You may want to look at Eric Lyon's paper "A Sample Accurate Triggering System for Pd and Max/MSP" and the related objects he's released.
Otherwise: rule #1 for scheduling in Max is "use one master metro and subdivide everything else."
That still leaves Gary's beef w/metro & Co., which is a very real issue. OTOH, there are now surely existing patches that rely on metro's latency when changing tempo.
I've written code for changing tempo that changes from extremely slow to extremely fast by doing the follow on receiving a tempo change:
1) Calculate proportion of inter-beat time remaining before next beat (deltaTRemaining)
2) Calculate multiply that by (deltaTNew/deltaTOld)
3) Cancel existing scheduled event and schedule a new event at the time calculated in step 2. Once that event occurs all following events are scheduled at intervals of deltaTNew (which by now is stored as an object member).
This is tedious but doable (it works effectively in lp.frrr~). However, to add this approach to metro it would, I think, also need to be a user flag to determine whether to use the old or the modified behavior in order to support backwards compatibility.