Looks like this should be uncommented

Missing the closing ` on AtomicU64

I have an idea of what this attribute does, but what about this function made you add it?

I'm also curious.

#[cold] is a hint to the compiler that it should use a calling convention that improves performance at the callsite under the assumption that a function is called infrequently: https://llvm.org/docs/LangRef.html#calling-conventions

in retrospect, I realise that #[cold] implies that a function should not be inlined, so I think the #[inline(never)] should be removed.

nit: i tend to prefer the module fn pattern of, e.g. pub fn handle_time() -> (Scope, InsertLayer) -- using the scope to produce layers is fine, but also doesn't really seem necessary (since the layer should be clone)...

Similarly, I'd be inclined to make a constructor that returns a 3-tuple rather than to hide the scopes in this struct.

I'd be happy to change all this code to return tuples, but I'm not sure if it's the right thing in this specific case. I think using tuples as return types is fine when the types in the tuple are heterogeneous (the compiler will notice if you try to call a Sender method on a Receiver, for example), but I'm a little leery of relying on tuple ordering to differentiate two different instances of the same type, like inbound/outbound.

I'm also curious.

if we unwrap here, why not unwrap above (where you use ok())?

The ok above could also be an unwrap; the reason it's ok() is because we are optionally returning a recorder from the filter, and the ok() lets us nicely chain the option, without the ok() the code is a bit more complex. I can make this consistent if that's preferred.

In general, I find the filter harder to read, and it's confusing because it at first seems like we're graceful to the lock being poisoned but, in fact, we just panic in the next access in that case.

let sz = self.recorders.read().unwrap().len();
if sz < idx {
  self.grow();
}
self.recorders.read().unwrap()

Is clearer about what it's doing, imo

The intention was to avoid reacquiring the read lock in the fast path. The code you posted is definitely more readable but will always acquire the read lock twice, even when we don't need to acquire the write lock. It is entirely possible that the performance hit from reacquiring it is not significant enough to justify making the code less clear, though.