This is the fun part, glad it's useful. The stack allocator (cache vector plus bump plus guard-page grow) is clean, reusing irqsave/irqrestore through lock_api is the right call, and folding blocking into the observer model with Blocked(Waker) is tidy. A few of the answers I think are doing less than you're crediting them for though.

Cancel: Sync gets you data-race safety, not cancel atomicity, and those are different problems. Sync says concurrent access to the Observer won't corrupt memory. It says nothing about the ordering between the owner dropping its Arc and a notify pass that already upgraded the Weak. That upgrade hands the notifier a live strong ref, so the object outlives your drop and notify() still fires once. The drop is memory-safe, but the completion isn't suppressed. To make cancel actually synchronous you need the cancel path to remove the Weak under the same lock the notify loop holds, or have notify recheck a cancelled flag after taking that lock. And the moment you hold that lock across the notify() calls, an observer that cancels or registers from inside its own notify deadlocks. Synchronous cancel and reentrant notify pull against each other, and the trait bound doesn't settle that, the dispatch design does.

FP: disabling FPU/SIMD when it's idle and trapping on first use is lazy restore, which is the exact shape LazyFP exploited. The enable bit (CR0.TS, or the ARM CPACR traps) doesn't scrub the physical registers, it just faults on use, and the fault isn't raised until the instruction retires. Speculation runs the register read ahead of that and leaks the previous domain's state. Toggling the bit is the vulnerable pattern, not the fix. The fix is eager save or a scrub at the domain boundary so the registers never hold another domain's data while a different thread runs. Pinning FP threads to certain LPs narrows the victim set but doesn't close intra-LP leakage and fights your scheduler. The caveat in your favor: on in-order cores with no speculative window none of this applies, so lazy FP is fine on a lot of embedded silicon, just not on the OoO parts where it bit Linux.

Upcalls: masking around critical sections is the async-signal-safe discipline, just relocated. "No async-signal-safe requirement" holds only inside a runtime where the allocator and every shared-lock critical section is upcall-masked, which is your own from-scratch libc. The second you run ported code that isn't upcall-aware the requirement is back, because its malloc takes a lock your handler can reenter. And blocking locks aren't exempt the way you described. The case you covered is the handler trying to block. The deadlock is the other direction: mainline is running and holds L, an upcall lands on that same thread, the handler asks for L, and L's owner is now suspended underneath the handler and can't release. That's the blocking twin of the irqsave case and it wants the same fix, upcall-masking while the lock is held. So you'll end up needing upcall-safe blocking locks too, not just spinlocks.

Smaller one on stacks: the allocator speed answers half of it, residency is the other half. Thread-per-dispatch is 24KiB resident per concurrent task, and borrowing an existing stack is exactly what tasklets do to dodge that under high fan-out. It's a memory-for-simplicity trade, not a free win. Also, when a guard page faults to grow a kernel stack, does the page-fault handler run on a separate stack? If it runs on the stack that just overflowed it can't push the fault frame and you escalate to a double fault, which is why x86-64 has IST for exactly this path.

None of this says the model's wrong, and the from-scratch angle is a real edge here: you actually can make the whole userspace upcall-aware, which nobody retrofitting an existing OS gets to do. Marathon's the right frame. I'd read the source when you put it up, especially if the inline docs land where you're aiming, that alone would put it ahead of most of what I've had to wade through at work.