It's overall a step in the right direction, but when I'd first heard of RC Pools I guess I was envisioning something a bit more automated and elegant. I'd imagine RC Pools tied to certain transaction types as opposed to individual user accounts, if such a thing is even possible.
I know that most (all?) posts contain some form of metadata that defines where the activity originated, as far as application, front end, tool, etc. I don't know if that's also true of voting activities. I feel that RC Pools should be tied to that information, instead of linked between each individual user account, which seems to still be a nightmare when scaling to tens and hundreds of thousands of users or more.
As an example, if Bob is posting his daily Actifit update, the system first draws from his own personal RC as is the case in what you describe above, if his balance is insufficient, it then draws from the Actifit RC Pool instead. Then Bob swings over to PeakD and makes a comment on a piece of art he really likes in the OnChain Art community. This RC cost is then auto picked up by either PeakD or OnChain Art. As a new user, Bob's experience is seamless, no requests need to be made for RC delegations, and the RC costs are being levied on the applications he's actually using. Otherwise, Bob may sign up through eSteem, get an RC delegation, discover SplinterLands, and spend his allotment of eSteem's RC on playing SplinterLands.
In the sort of system I describe, the three pools would essentially be relegated to different hierarchies of user, application, and community... quite possibly in that order of fallback. Applications and communities would ideally be able to set their own "rate limiting," blacklist certain users, etc. to control spamming and abuse of their RC. Applications could feasibly set a limit on both individual users and communities. In the example given above, PeakD may allow only 1% of their RC pool to be used toward any one community, ensuring a single popular community can't drain all their resources and harm the user experience. Then it's the responsibility of the community to power up HIVE and backstop with their own RC Pool to keep their members active and happy.
Communities are already tied to a singular account at creation that could serve as the RC Pool, Applications would have to have an account designated as their RC resource.
Whew. Hope that made some sort of logical sense.
Summation: Users should individually delegate into RC Pools of communities and applications that they want to support, but expenditure of RC Pools should be tied to transactions, not users, thereby removing the need to manage individual delegations across potentially millions of accounts. The minimal RC amount that all accounts are credited with at creation should be enough to ensure any new account can still make limited needed wallet transactions and other behaviors, while the heavy lifting of content creation and interactivity is automated on the backend and charged to the services being utilized.
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.