[bang~} bangs after each DSP block, but that's also when other control processing happens. If a GUI object generates a bang, does it run before or after [bang~] in that particular control processing block?

I think it's before, and I'm guessing that [bang~] is the last control message processed before the next DSP block is processed. Check out this test:
bang~ order.pd

I always get 0 when I click on the bang at the top. If [bang~] ran first, then its bang would clock the [timer] 1 DSP block later.

Is my test and conclusion correct?

well, if you put in a sub patch, with say [block~ 256 1 1] you can beat it

seems like it.
looking at sched_tick and the 2 different schedulers in m_sched.c it seems like the order is:

1. Gui is polled (where pd gets the 'click' message from tcl/tk, triggering the [bng] to output)
2. clock callbacks occur (this is where the [bang~]'s bang gets output) for the 'next' 64 samples
3. 'current' scheduler time is incremented 64 samples
4. audio is processed for the block (this is where [bang~] sets the clock callback for 0 logical time)

really, since [bang~] happens every cycle we should think about step 4 happening 1st because there will be a callback already on the set clock list from the dsp cycle before pd gets the click from the gui. so

4(4). [bang~] sets a clock callback for 0 logical time.
5(1). pd gets the 'click' event (still at that time) so [timer] is set and [spigot] is opened
6(2). the clock callbacks are triggered, and the clock callback for [bang~] triggers for logical time 0 (relative to the 'click'), outputting and triggering the [timer]
7(3). logical system time is incremented for the next dsp tick