That actually made a lot of sense, but there are a few issues with the system you are describing not taking into account the fact that it would require to rework the rc system to its core.
First there are currently no way of tracking some transactions and linking them to an app, there is actually a task for it somewhere. But it would be something like the "app" tag that we sometimes put in the post metadata, it's something that's useful for some UI changes here and there but shouldn't be used for important things like RC, because anyone can say "oh I am doing this post via actifit" even though it's not, and then steal RC from that pool, that could be solved by letting apps do some kind of signing on the transactions, but it complicates quite a bit the process.
And I disagree that it should be linked to transactions, because then nothing stops one spammer from using up all the RC and leaving the pool dry.
Without a doubt the biggest problem is that a system like I'm describing is ground up different than what's already in the works!
As long as pools can set automated rules on how their resources are allocated, I don't see the spam factor being problematic. Limiting accounts to (x) transactions or (x) RC per day would be sensible. It's a shame that transaction tracking isn't more robust, but it would certainly take a power user to tag their posts in such a way as to just siphon some RCs off an unrelated application. If you do consider that a serious concern, then that just speaks to the issue that primary front end applications are going to bear the brunt of RC costs, even when not used directly on their platform.
My main concerns are that it be pretty much seamless for new users to acquire an RC delegation, they shouldn't have to hunt for a frontend, application or user to provide it, request it, and wait for approval, and that applications can effectively manage their RC delegations. The pool as a "slush fund" of sorts with an attached ruleset is simpler than direct management of potentially millions of outgoing delegations, even if employing scripts and bots to help manage the task.
Side question:
In this example, are you able to differentiate in advance whether you're delegating to a user directly or their pool?
For instance, even without Eve setting a slot for Alice to delegate RC to, can't Alice delegate to Eve's pool without Eve's consent, and then Eve can simply route it to herself?
What's the purpose of the extra "whitelisting" step? I'm not seeing the benefit for the added complexity. We don't force people to accept a Hive Power delegation which is more impactful as it conveys RC and voting power in tandem, so why the extra limitation on RC alone?
If I'm understanding the system correctly, my suggestion for the current slot allocations would be to change #2 to the user account directly, and have their personal RC pool potentially feed into that with no approval or as seamlessly as possible, such that when Alice tries to delegate to Eve, Eve will see the benefits immediately without the complexity of needing to reassign a slot.