You are quite right, multiple OTE's to the same address are not so much unpredictable, as unlovely. They operate according to the rule: "last condition scanned always wins". The trouble is that if the instances of the address in use are scattered at random throughout the program (and not documented as such!!!) then the next poor sod who comes along has to search on all them all to find out which one is the last one being scanned at the moment. And if you are turning subroutines on and off dymanically this can become rapidly more trouble than it was worth.
Here are two ok ways to achieve what you want (and more exist I am sure):
1 In each subroutine create a unique flag to drive the output, and then in some section at the end of the program parallel them all together to drive the actual physical output. This method has the merit of making it easy to see which condition is actively driving the output and would be the approach I would normally take. (Remember that when you stop scanning a subroutine the last values you write will remain until overwritten by some other logic, ie you need to make sure each of these flags is turned off before you stop calling the subroutine!)
2. Another neat way around this is to allow multiple instances of the physical output address, BUT the first instance is implemented with an OTE, and ALL the subsequent instances are implemented with an OTL. This allows the address to be used mulitple times but the rule now is "any true condition scanned wins", which is what you want. This method is a little harder to troubleshoot and some folk would object to it, but if documented decently it does work quite well.
What I suggest is setting up a small test program to try both of the methods out and see which makes best sense in your application.