...I can't replicate the problem. Doesn't mean that there's not a problem. I generally don't use QA's or Enterprise Manager's of stored procs, as I keep the scripts external. I think it makes for easier source control. As a result, I've never used QA's object browser for the purpose.

The best way to tell if there's a cache issue is to dig into the tables and pull out the source from the underlying sys tables (that's how the QA and EM reconstruct the stored proc source code - at least that's how they're supposed to). Note, that the source for the stored proc is just a note in one of the tables, which is different than the compiled stored procedure itself.

Short of the possibility that you may be looking at a different database or server in QA than the one you are compiling, I couldn't explain the behavior. It's possible that QA has it's own cache for speed purposes, and that cache may be out of sync. But I would've that the MS would do a real time poll. But then that is assigning rational behavior based on the possible tradeoff of things slowing down.