Sorry for the confusion on this issue. To be very precise the SSD engine does often have an IO queue depth of 1 but it is due to waiting on reads. Each set or clear must do a BTree seek for each key (or range endpoint) and any time those seeks encounter a non-cached page they must wait for it. Then they can modify the page and “write” it but the write is buffered and not sent to disk until commit time, the idea being that the page may be modified again. I only recently realized this write buffering was happening, the interface made it not obvious because IAsyncFile::write() returns a Future but in the AsyncFileCached implementation it just returns Void() and queues the write for later.
The SSD engine does do up to 64 get() or getRange() operations at once, but that queue is independent of the Writer thread which must do its own reads serially (using the shared cache) as part of its update path.