Actually makes more sense to reply here...
About ternary logic: in practice it works because in a WHERE / ON clause, the value 'unknown' is generally equivalent to 'false' (and the same is true of the way the AND/OR operators work, i.e. if you think that a final value of 'unknown' is equivalent to 'false', which for the WHERE operator is the case, then the AND/OR operator is consistent with this)..
I agree this is slightly dubious but in a practical query it's fairly unlikely that you would specifically depend on the 'unknown' value, unless I'm missing something.
About database compatibility, this definitely works fine in Postgres (live on our system for ages), in MS SQL (just tested), and I'm fairly sure it also works in MySQL. However I agree it might not work on Oracle, hasn't been tested. Of course there is no chance that it can cause a bug in current system because any code that has an empty array already has a bug in current system.
Not having this facility is annoying and is a source of unexpected bugs (where the 'normal' case is that there will be some results in the array).
Perhaps another alternative would be to create a new version of get_in_or_equals that includes the entire SQL, i.e.
which could then result in the SQL values for different cases which would always be boolean true/false and never unknown:
x.groupid IN (3,4,5)
x.groupid = 4
therefore ensuring no ambiguity. (0=1 is the database-independent version of 'false', afaik...)
If anybody is actually strongly in favour of this, let me know, I might code it. Otherwise if you want to keep with the current developer-hostile approach, that's fine.