Given the history of the packages and factoring BC in, we're strapped no matter what. The only thing to be done is damage control for future and currently none-stable packages.
At least in-package consistency should be mandatory, regardless of properies' visibility IMO.
One more point to consider in that case is also indexes in $options arrays, which is widely used in PEAR packages.
Anyway, no matter which naming convention is agreed on, we can only make it a strong recommendation, with breaking of the rule only for extremely good reasons.
I think the CS should simply state "Choose either foo_bar or fooBar, but once chosen stick to that for all variables (private, protected and public) as well as any array keys. For instance $fooBar, $_barFoo and $options['myOption']. Acceptable formats include the classic C style (ie. foo_bar), the so-called hump back (ie. $fooBar) and hungarian notation (ie. $objLog)."
I don't really care what a person uses in their package (though I prefer humpBack, that's just me) as long as the ENTIRE package uses that. I don't want to see Package::$foo_bar followed by Package::$myVar.
I agree with Clay that we shouldn't force devs into naming their variables only one way, but I think we should force them to stick to a pattern.
This should be put into PEPr as an RFC and voted on.
--Joe