More details on why old API isn't great:

• Imagine hardware with 2 families, one that is graphics + compute + transfer, and one with compute + transfer. get_queue(transfer) returns the same queue handle as get_queue(compute), but the API makes it look like they are separate. And here is that exact situation on top of the line AMD hardware http://vulkan.gpuinfo.org/displayreport.php?id=25162#queuefamilies

• The custom QueueType enum made it appear as if each queue only supported 1 type of operations, hiding the complexity that actually exists.

• Trying to make each queue type have its "own" queue is not practical given the wide variety of queue families

The old API tried very hard to give 'unique' queues, get_dedicated_queue() for example, but the new API pushes that responsibility onto the user. There should be an easy way to determine uniqueness of queues. So.. the PR definitely isn't ready to merge.

struct QueueDetails {
    VkQueueFlags desired_flags;
    bool found = false;
    VkQueue queue;
    uint32_t queue_family_index;
};

std::vector<QueueDetails> desired_queues = {
    { GRAPHICS | TRANSFER | COMPUTE },
    { COMPUTE },
    { TRANSFER },
};

vkb::Device.get_queues(desired_queues);

if (desired_queues[0].found) {
    uber_queue = desired_queues[0].queue;
}
if (desired_queues[1].found) {
    compute_queue = desired_queues[0].queue;
}
if (desired_queues[2].found) {
    transfer = desired_queues[0].queue;
}

Just thinking out loud, here is a potential API for getting queues from different families.
The logic is that the app submits a list of requested queues by filling out the desired_flags member. Then, vk-bootstrap tries to find the best queue for each item, where each element that is satisfied is removed from considering for subsequent elements.
Ie, every queue found is guaranteed to be unique, and non-unique queues are 'not found'.