Hi,
You are of course free to do what you like but my advice is make features self contained. Trying to setup communications across features in some loosely coupled way sounds like a complex solution whereas just implement what you need inside the feature is a simple architecture that is completely de-coupled. Its hard enough making sure a feature deals correctly with the page event lifecycle on its own, trying to inject some additional event coupling/handling across features is not something I want to work with and sounds like it would be complex/difficult to implement and prone to bugs and side effects. And I really can't think of any benefit that can be achieved by this that cannot also be achieved with less complexity.
My advice is a keep it simple and don't try to make different features that talk to each other. Again this is just my advice as the architect of mojoPortal and you are free to do what you choose. None of the existing features talk to each other and I don't plan to make them talk to each other.
Again if you were expressing the problem in terms of some functionlity or use case you are trying to accomplish I could offer architecture advice about how I would tackle the problem but you are discussing it so far in terms of architecture suppositions and proposals that you envision but are not the way things are done in mojoPortal. I cannot really think of a way that one feature can handle events from another feature without some coupling and knowledge of the objects and events exposed by the other feature. I mean if the event passes a reference to the object you have to know what kind of object it is in order to do anything useful with it. I mean it could be made generic by passing messages instead of objects but you still have to be able to understand the messages sent by an object so there is still coupling. Reflection is a no good because it can't work in Medium Trust.
Things that handle UserCreated event have to know about the SiteUser object in order to use it, things that handle PageCreated have to know about the PageSettings object and therefore these things are coupled, though it is somewhat loose because handlers can be added or removed by configuration. These are core object though not feature objects so its less ugly to have dependencies on them then to have dependencies across features.
Better to keep things self contained inside a feature and keep it simple in my opinion.
Best,
Joe