Complex is easy, simple is hard.
When it comes to introducing new functionality, especially one that is inherently more complex, I try and look towards the benefits of keeping it simple.
- Less of a learning curve
- Easier to understand other peoples code
- Easier to maintain
And then think about whether the advantages of the new functionality outweighs these.
In this case, the ability to define custom matching algorithms, albeit cool and logical the way you've proposed it, does it add more value than cost?
At one extreme, I see a future where every plug-in defines a corresponding matching algorithm. At that point, to even begin to understand a series of plug-ins - especially those mixed and matched from elsewhere - would see an increase in the time required to understand it.
On the other extreme, where there is only one matching algorithm, you need to get creative with the little you've got in order to achieve complex behaviour.
Having said that, it's also possible that families as it exists today is a subset of what this does. That defining your own matching algorithm could be the de facto method of associating plug-ins to instances and that it makes for both more flexibility and simplicity.
Let's explore it.
First off, I'm interested in what you mentioned @tokejepsen about your requirement in pyblish-ftrack and what hoops you jump to currently in order to achieve the necessary effect.