Write down what would sit on top of these queues, and name it

[pathscale]

A design note. Nothing is built, and the note says so.

This argument has been had twice in conversation and written down neither time, which is how it gets re-litigated a third time.

What it records

Where this crate sits. The README is already precise — fifo targets Tokio's internal queue, lifo targets the Chase-Lev deque. Only one of those is substitutable: Tokio's queue is private, so nobody migrates to this crate from Tokio, while crossbeam-deque is public and is what rayon-core runs on. That makes the realistic customer a library author building a scheduler, not an application picking a runtime. fanout is in neither camp — no futures or I/O driver, so not Tokio; no join/scope/par_iter, so not rayon.

The layer ladder, and the boundary that matters: Host (park, unpark, clock) is already the entire OS seam, so JoinHandle, block_on, futures and timers all keep the no_std core. Only an I/O driver ends it. Stopping before that is a coherent product — an async runtime that needs no operating system — rather than a half-built Tokio.

The tension, named. fanout's own docs say tasks are independent by construction, no join, no completion. That is why it is cheap, so every layer above belongs beside submit rather than instead of it.

The name: Nagoya, when it graduates into its own crate, and not before. With the rejected candidates and their reasons — osaka is taken by an abandoned async runtime (25,650 downloads, last touched 2019), which is the one collision worth avoiding; kyoto is taken by a dormant cache crate; tokyo is a typosquat of the project whose queue design this builds on, and mislabels the thing exactly when the interesting claim is "no operating system required".

Docs only — no code changes.

[pathscale]

Folded into #4 as 169865d, cherry-picked so the branch stays linear. Closing this so ps-st3 carries one PR.