These are ideas almost purely as conveyed by Jonathan Shapiro. I have talked to him on the phone several times, the most recently in the last hour. They concern how domain code that multiplexes some facility can efficiently order its work. (More work is needed here to specify the problem better.)
Here are the proposed kernel design changes as I understand them. This is entirely from the extra kernel perspective even though the internal designs are in fairly plain view.
There is a newly architected domain root slot R that, like the brand slot, is inaccessible via the domain service key. This slot is void while the domain runs. There is a newly architected retry kernel invocation that is much like those the key jump family. Retry designates a key that we will assume here is a resume key. It also designates a smallish piece of data, ID, perhaps 8 or 16 bits long. The exit block also designates a “redirect key”. In the intended use the domain will become available as its next action and perhaps this should be the outcome of retry, in which case an entry block will also be specified by retry.
The redirect key will be placed in slot R of the waiting domain specified by the resume key. That domain enters the milling state, a new state in the running, waiting and available suite. The milling state is busy, i.e. not available.
In the intended use the redirect key will be a wrapper key for a node whose format key