I agree that ability to group nodes and comment them would be VERY useful. But this request (in my opinion) is more for option 1) than 2).
Maybe it depends on how complex subcompositions you want to save for another use. From my experience current behavior cleans up some very simple reusable subcompositions. But it's very inconvenient in some more complex situations. I build huge sets of nodes which take many options and produce some live image (for example drawing by mouse or tablet). In that case I have to filter almost ALL incoming ports for unneeded events (for options like thickness, opacity, color which change sometimes) because of ONE incoming port (mouse position which changes more than 100 times/sec). In that case there is hundreds of "fake" events generated due to current behavior of incoming ports. Performance is VERY poor.
So I think there is some third option you did not mentioned: reuse of node which takes params and produces results based on variously changing params :)
@jaymie, sorry for such a long time of silence :)
Yes, I agree that changing to event-through-one behavior universally is good idea. In that case you can achieve event-through-all behavior more easily than in opposite direction (I'm curious if I wrote that in English :)
But, of course, ability to choose a behavior of ports for every subcomposition would be great.
My main beef with the current sub composition behaviour is that on the outside, it looks like any other node, but it's impossible to build a sub composition that has actions associated with event arrival at specific ports, which is very common among Vuo's included nodes. The sub composition I submitted with the original (but report) post was a demonstration of this issue, using a Count node essentially inside a wrapper. Putting it inside a sub composition killed its functionality.
We need (or at the very least, I want) to be able to have better control and flexibility over events flowing into a sub composition, otherwise the ability to expand the functionality of Vuo will be limited only to people who want to program that functionality in C. That is a limitation I'm not willing to be stuck with, as it misses the point of being able to program completely in a visual environment.
The nice thing about the proposed change is that it will allow a composer to implement the old behaviour while allowing for far more complex functionality if desired.