Each bank has a non-negative meter like limit that goes up and down with sells and buys. Some bank facets allow reading and writing the bank limit, others do not. When a buy happens and a bank limit is 0, that bank's keeper in invoked with a key to the bank that can change the limit. (like meters)
The program that would confine another must acquire a bank, the superior keepers of which are all covert savvy. Facets with read limit authority to that bank and its superiors must be unavailable directly or indirectly, to any covert receiver. This means that they must conspire to some degree to muffle demand for space. All such schemes seem to require a trade-off between extra real space, or long delays in granting requests for large amounts of space.
There is a dead-lock to be avoided. When the bank keeper runs, what continuation (resume key) does it hold? If it is to the bank then the facet is useless for the bank is busy. If it is to the buyer, then the bank is available, unless, of course, someone beats the keeper to the bank and orders another page, whereupon the bank will stall trying to reinvoke the keeper.
Consider coroutine relationship between bank and keeper.
It is instructive to see how this is avoided in other keeper designs. Something that that note does not say is that the code defining the kept object, being kernel code, is in a position to do things that domain code seems unable to do. When a domain's action is blocked by some obstacle, the kernel may invoke some keeper that may be able to remove that obstacle. While that keeper runs, the blocked domain is left in the state just before encountering the obstacle and the keeper holds some sort of resume key to that domain. Commonly the keeper will remove the obstacle and return to the resume key whereupon things proceed much as if the obstacle had not been there.
When the logic that defines the bank finds that the limit is zero, the bank already holds the order (message) for new storage and may not have its "hands on" the sender of that message. Indeed the sender may have forked the bank in which case the bank has the only copy of the order. The normal solution is for the bank to remain busy until the order has been processed, but meanwhile the bank must respond to orders from its keeper if the obstacle is to be removed.
Suppose that there were a new domain state bit C. It can be set and read by the domain service key but is constant in this exercise. When domain X invokes a start key to a domain Y with C set, a restart key for X is delivered to Y, even if the invocation was a fork! The PC of X remains so that if the restart key were invoked, the bank invoker would invoke the bank again with the same message. This state of X is like the state of a domain while kernel code is interpreting a message to a primitive kernel object that the domain invoked. If bank domains were in this state then when the bank invoked its keeper it could pass the continuation (restart key) to its keeper. If the keeper thinks it has removed an obstacle it can invoke that continuation and the bank will be invoked once more with better results. The message to the modified bank would contain a resume key to the bank instead of what the exit block of the invoker had specified. Here is more detail on such a design. (Think domain forks bank.) It might be simpler to enforce a rule that banks must be called.
I vote for A. I think there are many fewer bank keepers and it is not important to share them. There remains the problem of shared factories being stuck on non-prompt banks.