Tony, is there something driving the strong push for protected? Or are you just saying that's the better way to go by default?

I believe we discussed the idea that as a rule of thumb, private (but accessible) is the way to go, unless there's a use case we're targeting which warrants opening stuff up. It gives the library much needed future flexibility to modify the implementations behind the public API (for example for performance, or to extend signatures etc - something I'm hitting right now with the Attribute/Base/Event optimizations). 

Good thing is that it's JS (and not Java or C++), so worst case, if we're too conservative, and don't give users enough access for customizations they may need, they can still use the functions, and request that they be opened up. But it's better to wait for that input, than open up everything by default and then be painted into a corner when we need to refactor in my opinion.

Satyam's point about 'aggregates' being public would be a reasonable reason which would drive us to make the above method protected, but from what I can tell, 'aggregates' is undocumented, and hence is not part of the public API doc. Also, I haven't read the before code in detail, but going by what Satyam is saying, if the implementation functions were pure privates to begin with, users may not have been able to effectively extend `aggregates` before anyway - since they didn't have access to extend the functions which use `aggregates`.

Worth considering, I think, before we open up more than is required.