I don't think that this "hide and reveal" approach is sound/wise. You can implement whatever logic in your methods so they work differently depending on the context, but what do you mean by "hiding methods/properties"? Could you not just avoid using them when not relevant? Very few end users really use class/object introspection mechanisms actually, and in my opinion it would be a mistake to try hiding anything to those who do. Actually, as a user, I much prefer having a clean object/class that triggers an error() when I am using one of its methods inappropriately, than a class that tricks introspection mechanisms.
I don't think that you can dynamically make private properties/methods public and vice versa. If you really want to manage hiding properties/methods, the only trick that I can think of is to overload METHODS, FIELDNAMES, and PROPERTIES. I don't think that it would be wise to overload METACLASS, because you would not be able to reproduce easily its output.