@pythonesque pointed out that having the default queue on the device is causing a few issues.

First, it introduces a circular dependency. Device points to a queue, but a queue is owned by the device. Resources, owned by a device, submitted in command buffers to a queue, are held alive by the queue for the duration of GPU use of them. So "Resource <- Queue <- Device" and "Resource -> Device".

Arguably, this is an implementation issue. Generally, however, designing a structure of classes without (or with minimum) circular dependencies could be considered a better design.

Secondly, in the multi-queue world, it would harm the ability of users to control what's happening on the queues. Since the queue argument isn't participating directly, it's used implicitly, and it makes it more difficult to reason about the queue loads.

The list of operations that currently depend on the default queue:

1. command encoder creation - Associate command encoding with a queue #1278
2. unmapping of buffers created with "mappedAtCreation". A queue needs to do a copy operation from the staging area into the GPU memory of such buffer.
3. maybe something is missing in this list?