i just had another look at your bug report that azeno mentioned above, checked your patch again and our solution from back then. I also had another look at this one here: https://vvvv.org/blog/mixed-data-over-that-same-ol-pin which again needed some changes on the node pin system.
All in all i am positive about the changes we did to the system since then, as they not only conceptually cleared up a long-standing question, added features, simplified the node connection concept and still also got rid of the subtle bugs you reported in that small patch https://vvvv.org/sites/default/files/user-files/PinConnection_Issue.v4p
The long standing question was how we need to interpret the list of needed interfaces. Does every interface need to be supported by the source or just any.
In c# it is easy to express that a certain data type supports different interfaces. This is the "and" model: a certain class comes in different shapes and supports this "and" that interface. So basically when writing c# code and exposing all the different interfaces to vvvv you already express "and". However there is no way to state in c# that you somewhere expect data to be of this "or" that type. You would take "object" or any other super-type and then test for the sub-types. This now aligns very well with how vvvv deals with lists of interfaces. Sources typically support many, sinks typically need just one. In short: we are happy with the rework and now want to help you to fix the issue that suffered from our breaking change.
What you can do is
* use the feature https://vvvv.org/blog/mixed-data-over-that-same-ol-pin and test for interfaces as mentioned (plugin interface v1) via
* introduce a base interface and expect that on your input (plugin interface v2) via