I found the Advanced button, it was hidden.
But the issue still remains that Jenkins is not handling starting jobs correctly in an upstream/downstream situation.
In abstract, here's my setup job A is dependent on section A (using SVN).
If A runs, it will spawn job B. Job B can also run if section B (using SVN) changes. If job B runs, it spawns job C (which has no SVN dependencies).
So here's the scenario changes comes into to SVN B, spawn job B, it completes and spawn job C. While job C is running, another changes comes into SVN B. That queues job B but won't run as job C is running. Still while C is running, a SVN changes comes into area A. That queues job A and doesn't run as job C is still running. This is all as expected.
Now job C finishes. Jobs A and B are queued and neither one starts (and I caught this when both had been in queue for over 4 hours). If I manually try to start either, nothing happens and both remained queued.
The only solution was to kill one job (in my case I killed B, since I knew after A ran it would run B anyways – and get B's SVN changes). Immediately upon killing B in the queued state, A started running. (and when it finished, B ran, finished, and ran C).
So it looks to me like there's a bug in Jenkins 1.611 (and was in 1.610) – where if 2 jobs are queued that are in a upstream/downstream relationship and both are configured to not run if upstream/downstream is running, then it will start neither.
FYI, I was on an old version of Jenkins (1.530) and this functionality was working just fine. I upgraded to 1.610 for other features and then later discovered this broke.
Also, I have uninstalled Build Blocker plugin (and restarted Jenkins) and my above ABC scenario still exists. So I don't think Build Blocker plugin has anything to do with the issue, just a bug in Jenkins.