The Flex Queue is its own unique queue, separate from the asynchronous queue. Basically, until a Batchable process starts, it is in the Flex Queue, and can have its priority changed. Once the system has resources, it starts building up jobs to perform in the asynchronous queue. This includes start, execute, and finish methods of Schedulable, Queueable, and Batchable, as well as future methods. I can't find an official Salesforce page with this image, but several blog posts show this depiction of asynchronous processing:

If anyone can source the appropriate Salesforce page this came from, please feel free to edit this answer.

As you can see, Bulk API, Batch, future (etc) all are in a per-org queue, and they are interleaved. There's a special rule that says that if there are more than 12 asynchronous calls from a single org, another org will get a chance to execute^{[citation needed]}. It appears this may have changed, as the current documentation for @future says:

Avoid adding large numbers of future methods to the asynchronous queue, if possible. If more than 2,000 unprocessed requests from a single organization are in the queue, any additional requests from the same organization will be delayed while the queue handles requests from other organizations.

There's no such thing as different queues for different types of asynchronous processes. Salesforce considers each of these asynchronous calls equally, with some minor caveats (namely, one one Batchable start method may execute at a time per org). There is the Flex queue, and the asynchronous queue, which are two distinct queues in the system.

Generally speaking, asynchronous calls are processed in the order they are received, but if an org has too many items in the asynchronous queue, the queue may be reordered. Also, chaining requests (e.g. Queueable calling Queueable) will impose a minimum delay between executions to give other orgs a chance to execute.