subpatchers are first (so that you can initialise them from outside), and otherwise it is right to left, bottom to top, like everything.
but i´d recommend to control the order yourself anyway, everywhere, it is just safer.
couple of things, how would you control the order yourself (other than via positioning)
i was hoping to create a unique name when the patcher loads and store it so that subpatchers can use it for send/recieve comms - sounds like I#d have to do this in a specific subpatcher and make sure this fires first rather than to it in the main patcher?
there are two main strategies to control the order.
avoid that controlling the order is necessary.
build your abstractions and subpatches always so they have a useful init status, then let the parent level control its parameters via arguments and/or inlets.
where order is still needed, use right to left order.
[t b b b b]
[500.] [600.] [700.] [800.]
[object4] [object3] [subpatcher2] [subpatcher1]
i think you find out that you almost never need to control the order when your subpatchers and abstractions are organized nicely. where you do, a simple t b b and a connection makes sure what is banged first.
one possible alternative is to use abstractions inside abstractions instead of [loadbang].
[myloadbang] could, for example, contain a [loadbang] which is only passing a [gate] when a certain number is received via a [receive] object. or you can use just a [select] object.
inside the [myloadbang] abstraction you would have something like this:
[recieve myloadbang]-[select #1]
in the parent level you will do nothing more than:
[loadbang]-[uzi 25](second outlet)-[forward myloadbang]