The whitepaper for that is https://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen.

Proposal: credit-driven scheduling

The idea is to make resource share apply to overall credit, not to individual resources types. If two projects have the same resource share, they should have the same RAC. Scheduling decisions should give preference to projects whose share of RAC is less than their resource share.

There are problems with using project-granted credit as a basis for this approach:

There may be a long and variable delay between completing a job and getting credit for it.
Jobs may fail to get credit, e.g. because they don't validate.

Hence we will use a surrogate called estimated credit, maintained by the client. If projects grant credit fairly, and if all jobs validate, then estimated credit is roughly equal to granted credit over the long term.

And that's what the current BOINC v7 clients do.

Because REC estimates credit much more closely in alignment with the formal definition of the cobblestone than many projects do, REC (and consequently Resource Share) follow flopcounting much more closely than they follow actual granted credit.

I personally suspect that the 'flops' which are 'counted' for REC are those declared by the programmer/deployment administrator in <rsc_fpops_est>. That's my theory (partly) for why SETI's MB and AP tasks award different RAC, and likewise Albert's Arecibo and Perseus Arm surveys (IIRC those were the two apps which trended to different limit values).