Controlled Transaction Blocking - Resume Behavior
Example 1: You shouldn't care. The process is much more involved than it seems, and I don't think you have any guarantee. The 3 commands go into the queue in order. The first one is pulled and executed, when the second is attempted, the engine may choose to put it back in queue if it waits for more than some threshold, and the third may be pulled and attempted. if it happens that the resources are now free, the 3rd will be executed first. if not, it may go back in queue again.

Example 2: I think the above explains it, and the answer to both your questions is no AFAIK, unless you develop an execution buffer of your own. Don't.

Rationale: Now you got to the core challenge, which should really have been the title - "How to deal with deadlocks". You assumed that your 'global lock table' solution is the only way to make things right, but I think the price of losing all concurrency is not worth it. It would be easier just to have the procedures executed serially using a scheduler of some sort. You will open a Pandora box with this approach that will be hard to close. Queuing and syncing is a very complicated challenge.

If I were in your place, I would first investigate the root cause of the deadlocks. Sometimes, something as simple as adding or modifying an index can solve it.
If you post your deadlock graphs here, along with the involved queries with their execution plans, people will help you pin point the root issue.

HTH