Hello,
First of all if you haven't already, please check out my proposal for blockchain development on hivedao: https://hivedao.com/proposals/97
This the kind of posts that I want to do now and then on chain to gather some feedback and ideas about features and ongoing hive core work.
So here's some history on RC delegations, it's a feature that was worked on over a few years by the steemit team, and was supposed to ship with the smt hard fork, I figured this was a very important feature to have asap and we shouldn't wait on smts to have it. The problem is that the code is quite different between the SMT branch (where smts are done) and the main branch (the one that powers the chain right now).
When the steemit team said "SMT development change almost every element of the chain" they weren't kidding. So the challenge was to extract the code and then adapt it to work without the rest of the SMT code. Which can be quite tricky as I had to dig up some changes that were made back in 2018.
Then I realized that there was some bugs, so I set out to fix them and finally I got a working proof of concept.
FYI: it won't go live for hf24 because we don't want such a big change in hf24 and also there's some discussions to be had and potentially modifications to be done depending on your feedback.
Here's currently how RC delegations work:
Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).
There is a notion of delegation slots, each account got 3 slots from which they can receive delegations. meaning they can receive rc from at most from 3 pools, also, each slot can only receive from a specific pool. If you are not "whitelisted" you can't delegate to an user.
By default:
Slot 1 is set to the account creator of the account, and only the account creator can change that slot
Slot 2 is set to the recovery account, and only the recovery account or a top witness can change that slot
Slot 3 is set to null, and the account can change that slot.
it may seem a bit odd how the user don't "own" 2/3 of his slots, but it's designed in order to offload the complexity (setting up slots etc) to power users (witnesses/account creators/recovery partners) instead of putting that burden on the user.
Most of the use cases for rc delegations are linked to account creation anyways, and that use case is handled by default, then there's games or other operation intensive applications and those could have a button to "ask for rc delegation" that would make the user set his personal slot to the game and then the app would delegate to it.
It's worth noting that if you change your slot, you lose your previous delegation on that slot.
Pool work on an oversubscription model: (thanks 
Let's say Alice delegates 100 RC to an RC Pool.
That pool can then delegates 30 RC to Bob, Carol, Dave, and Eugene.
There is a total of 120 RC delegated, but only 100 RC in the pool.
Is that a problem? No.The implementation allows each of the out delegations to use up to the delegation's worth of RC, but that is charged to the pool.
If Bob uses all 30 RC and no one else does, Bob will no longer have access to RC from the pool until his regenerates, even though to pool still has 70 RC available. However, if Bob, Carol, and Dave all use 30 RC, then Eugene will only be able to use 10 RC before he cannot access any more.
Although he has RC still available from the delegation, because the pool ran out of RC, Eugene does not have any to use.
This is useful for this use case: Large stake holder making many small delegations, such as Steemit delegating to new users via the faucet (back when that was a thing). Users will consume their RC, but because not all users are retained, this can be significantly over subscribed.
No it will stay the same
The RC used is in priority the account's own rc (hive power + delegated hive power), then if that's not enough, delegated RC is used.
Yes.
40
To be clear an account can contribute to 40 pools, which will then be used to delegate RC to as many accounts as they want (way more than 40).
Let's say the same thing but with a soup analogy:
A user can contribute to 40 different pots, but each one of those pots can be used to feed as many people as he wants.
Yes
No
Now, question is, what do you think of that implementation ? Are there things you would change ? I am open to coding any changes. But keep in mind there are performance and complexity considerations to take into account (for instance that's why we don't have like 50 slots per account).
Some early feedback include allowing users to change all their slots if they want to, because a lot of slot 1 (account creator slot) would be blocked and never used since they are linked to the 
And again, please consider voting on my core development proposal here https://hivedao.com/proposals/97
