I think this is according to the spec. A rIC will always be scheduled into the next idle period at the earliest. This is to prevent busy looping in cases like the following:

function callback(deadline) {
  if (deadline.timeRemaining() < limit)
    requestIdleCallback(callback);
  else
    doWork();
}

If we have multiple outstanding idle callbacks which have been scheduled in the previous idle period (or earlier), then Chrome will happily run as many as it has time for in a single frame.

+igrigorik

Yes this is part of the spec. I'll reach out to the Firefox implementers to ensure we are both consistent.

Where does the spec say that?

(Remember that Notes in the spec aren't normative.)

It's outlined in section 2 to explain the rational behind the decision (as you say, non-normative). The normative description is in section 5.1, explicitly, where we define when idle periods start:

 1. Let last_deadline be the last idle period deadline associated with the    
    current event loop, or 0 if no previous deadline exists.
 2. If last_deadline is greater than the current time: 
    1. Wait until the current time is greater than or equal to last_deadline.
 ...

So if you started an idle period with a deadline that would end at the start of the next frame, then you can't start another idle period until that next frame has started. Since callbacks are only moved from doclist to runlist at the start of idle periods, any rICs posted within one idle period can't be run until the next idle period.

So that doesn't mean next frame but just after next non-idle thing browser does, right?
The case being:
rAF-tick, idle-period, timer-tick, <some spare time>, rAF-tick.
 <some spare time> can be used for idle callbacks too, right?

Idle periods can be whenever the browser wants them to be, however the constraint is that once you start an idle period with deadline x, you can't start another idle period until after time x. So if you start one at the end of a frame and set the deadline for the expected start time of the next frame, you can't start another one until after that time (leading to the 1 rIC per frame constraint). 

A browser could allow more per frame, however it would then have to chunk up the inter-frame time period into multiple distinct idle periods, meaning the deadline for each would be shorter, which would mean tasks which need (for example) 10ms to run wouldn't see any inter-frame rICs with a long enough deadline.

There has been talk of having an option (on IdleCallbackOptions) which allows the user to request a rIC callback in the same idle period, but this needs to be optional to allow the pattern in Example 2 of the spec without causing rICs which are waiting for a longer deadline to end up eating all CPU time between frames.

For the explicit example you mention, if you know the timer-tick is scheduled for the middle of a inter-frame period you could do exactly what you mention, as long as the first rIC only got a deadline up to the time the timer is scheduled for. We do this for long idle tasks in Chrome, but not for inter-frame ones. 

skyostil@ might be an interesting thing to try depending on how people use rIC with setTimeout.