I replied on that other thread.
Fixing bugs is just part of support. This is open source software. So it is free, provided "as is" (defined in our terms and conditions), entirely funded through support subscriptions, and we can only expend the time we get funded for. If we were charging lots of money for the product, we could just fix bugs as they get reported. But in an open source model, bugs reported in Community just go in the queue, and get fixed as and when we have time. For paid subscribers, we can expend an amount of effort commensurate with the subscription amount, making a reasonable "best effort" within the time that a sub justifies, and taking into account how many people the bug affects and the time to fix. So a bug which affects everyone is easier justifying time on than a corner case one which only affects a very small number of people.
I'm explaining this as well as I can because as time goes by, this is becoming more of a problem for us. Most of the "easy" bugs / features have been fixed, so what remain are the harder ones. I'm guessing this one would take a whole day to do. And you are the only person who has reported it. So even if you had a Pro sub, that'd still mean we'd be earning less than $10/hour, split two ways, for fixing it. I could earn twice that working at McDonalds. So we're currently trying to work out a better way of handling this kind of thing than an "all you can eat" subscription system. This response is me thinking out loud, and if you have any thoughts, please express them.
In this case, it's not really a bug, it's simply that the isunique was never intended to work with "multi select" joins that store their data on a separate table. So this is really a feature request, to add that capability to the validation.
-- hugh
