The CLR's own thread pool, not a hand-rolled one.

No owned worker pool: Bus's constructor raises ThreadPool.SetMinThreads to an advisory floor so a burst of work isn't stalled behind the pool's default gradual thread-injection rate, then drains every stage on the shared, process-wide pool. That's this port's one real structural divergence from the shared design's “one shared worker pool” — here it's shared with the whole process, not scoped to one bus. Consequence: Shutdown can't Join() a pool it doesn't own, so an explicit Interlocked-counted in-flight tracker, not queue depth alone, is what shutdown actually waits on.

ConcurrentDictionary covers the channel registry, dead-letter map, callback map, and per-channel attempts map with no manual locking — a genuine simplification over the C++/Rust ports' guarded maps. Bus itself is a plain class with no Arc/shared_ptr-equivalent wrapper; the CLR's GC already keeps it alive for as long as a scheduled work item's closure references it.

The one fix attempted, reverted, then solved differently. The original Channel had a single lock guarding both push and pop on a LinkedList — the same pattern C++ had before its fix. Porting C++'s exact two-lock, pre-allocated design made things worse, not better (bimodal 95–390ms latency) — the working theory is that any blocking wait inside a work item scheduled on the shared ThreadPool gets punished by its gradual thread-injection throttling. Reverted rather than shipped as an uncertain win. A later pass fixed the real bottleneck with a different mechanism instead: two lock-free ConcurrentQueue lanes (fresh admissions and retries drained separately, retries always ahead), whose only wait (Block back-pressure) runs on the producer's own thread, never inside a ThreadPool-scheduled drain.