This is a promising but premature approach.
In some applications it is too difficult or too expensive to reserve the right amount. It would be to call a bank keeper when the pool was exhausted. This particular keeper would have the job of monitoring the signals that emerged from the confined object and modulate, limit and obfuscate them. In particular it could report on the amount of information that escaped as it allocated temporary storage from unreserved resources.
With the factory and bank logic of the 370 system, the factory requires a prompt bank, and that bank denies the space request instead of stalling. This covert channel is thus checked but the confined application is likely broken when it wasn’t really its fault.
We could require a distinct factory within the realm but I really don’t like that for then the factory builder would have to consider whether a particular factory required this extra expense. As it is now factories just naturally produce discreet yields at no extra cost.
One unpromising solution observes that the continuation for the invocation of the factory’s requestor key must be a resume key. Imagine another primitive capability that would “back up” the domain referred to by some proferred resume key. The factory upon rejection would back up its requestor and send a message to the bank to wake up this guy when space was available. This is sort of like what the kernel does when it must stall a domain for I/O while it serves other domains. Ugly! Perhaps the new primitive would consume the resume key and produce a restart key. I think that this might avoid introducing more domain states. After this substitution the domain would be waiting but the situation would be as if a meter trap had occurred. The new primitive would not operate on a restart key. This would avoid the issue of multiple backup operations. Perhaps the distinction between resume and restart keys could originally better have been addressed in additional domain state instead of key type variety.