I guess for the event loop we either have to switch to CLOCK_BOOTTIME (timerfd supports that), or decouple absolute timestamps from Crystal::System::Time.instant. That would mean using only relative timers.
It might be best to encapsulate the clock entirely in the event loop, i.e. have no direct integration with Time::Instant.

We need absolute timers in the event loop: while the event operation can be retried multiple times, the timeout is a fixed point in time.

We could rework the epoll and io_uring evloops to recalculate a relative timeout every time but... to include suspend time we'd still have to tell timerfd and io_uring to use CLOCK_BOOTTIME 🤷

So, let's just use CLOCK_BOOTTIME to avoid the issue for starters, and add a note to keep the clocks synced.

Neither NetBSD, OpenBSD or Solaris detail or guarantee whether their clock count suspended time. Shouldn't we use CLOCK_BOOTIME when it's defined, and fallback to CLOCK_MONOTONIC otherwise?

CLOCK_MONOTONIC is the standardized clock in POSIX. We need to use different clocks on Darwin and Linux because they are deviating from the standard.
It seems OpenBSD is the only environment where we have a choice to use one or the other. But it's moot because their implementation is identical: They both delegate to nanouptime, so suspended time is included (in contrast to CLOCK_UPTIME and nanoruntime).
As I understand it, the idiomatic clock on BSD systems is the standard CLOCK_MONOTONIC. OpenBSD has added CLOCK_BOOTTIME only for source compatibility with Linux.