> The performance issue was that the asyncio core loop was running in a loop
but did nothing because of time rounding. When the next event was in a few
nanoseconds, the e event burnt the CPU during <clock resolution> seconds.
It can be 15 ms on Windows or 1 ms when using poll() for example. It's not
just clock resolution, also the resolution of the selector.

Hm.  I glanced through the issues you linked, and it looks like it's a valid concern for a micro-benchmark.  But I don't see how a performance of a real-world application can be affected here.  IOW, the "self.time() + self._clock_resolution" line looks like an optimization for a particular micro-benchmark.  I'm sure we can construct another micro-benchmark that would benefit from "self.time() - self._clock_resolution".

I think we should value correctness more than micro-benchmarks.