In-process Event Bus

Use a token-indexed subscription registry and a dispatcher that iterates a stable snapshot in registration order. Isolate listener failures and define synchronous, reentrant and optional asynchronous behavior explicitly.

1. Subscribe validates the topic/callback and stores a new token with a monotonically increasing registration order. Duplicate callback subscriptions remain separate registrations.
2. Publish captures the topic’s subscriptions before invoking user code. Treat event payloads as immutable supported values; snapshot or freeze them according to the library’s explicit payload contract.
3. Invoke snapshot listeners in registration order. Catch each listener error, collect it in PublishResult and report it through a guarded error handler. Error-handler failures are collected without recursive event publication.
4. Unsubscribe removes exactly one token and is idempotent. Enforce a nesting-depth limit for synchronous reentrant publish. If async delivery is added, bound its queue and return an overload result when full.

• A listener added during publish starts receiving on the next publication.
• Removing a listener during publish obeys snapshot semantics.
• One throwing listener does not stop subsequent snapshot listeners.
• Repeated unsubscribe and excessive nested publication behave deterministically.

Trade-offs to explain

• Synchronous dispatch is easy to reason about but a slow listener delays the publisher.
• Snapshot unsubscribe takes effect on future publications; applications needing immediate cancellation require a different documented contract.
• This bus has no durability or cross-process delivery guarantee. A broker-backed design needs acknowledgements and replay semantics.