@alexanderbrevig yeah I get what you're saying. And thanks for following up, too!
Some time ago I tried to enforce
PUBLIC/PROTECTED/PRIVATE sections in my source files and place members inside them accordingly but soon I figured it's too cumbersome and found myself not following this discipline. It takes time to scroll between different parts of the file and you might lose your thought while performing such jumps. Not to mention the extra burden if you decide to change member visibility.
Instead I learned how important documenting your code is and eventually found a good documentation generator that puts different types of class members into different sections (config parameters / runtime properties / methods / events... btw what is your approach to defining & documenting events?) and allows the reader to easily filter out private or inherited members if he wants to.
The only convention I follow is putting config variables/properties first in class definition, then the constructor, then all other methods, like they do in ExtJS. I find it more comfortable to logically group methods (this is context-aware), not by visibility. That way it's easier to follow the chain when learning how things work.
As I pointed out above, and I'll make it clearer, I don't feel there need to be different "levels of verbosity" inside the source code, the source code is already the maximum level of detail once you get there (if source code is available at all), it's all in front of you. All the "reasons" for visiting the code you listed in your original post actually look like perfect cases for visiting documentation instead. Again, if documentation doesn't give that to you (public api? preconditions? default values & constants? cmon, that all must be in the docs!), then you should really just improve the documentation, not shuffle stuff inside your source files.