contrib/intarray vs empty arrays

I just got rid of the contrib/intarray duplicates of <@ and @>,
as we discussed here:
http://archives.postgresql.org/message-id/17021.1234474178@sss.pgh.pa.us

While I was testing this I realized that I wasn't getting quite the same
answers :-(. In particular, it seems that the core operators consider
an empty array to be contained in anything else, while intarray will
only return true for two nonempty arrays.

I would just go change that, except that the *real* problem is it means
GIN index searches behave differently from the operators themselves.
Using intarray's regression database,

contrib_regression=# select * from test__int where a <@ array[1,2];
a
-------
{1,1}
(1 row)

contrib_regression=# drop index text_idx;
DROP INDEX
contrib_regression=# select * from test__int where a <@ array[1,2];
a
-------
{}
{}
{}
{}
{}
{}
{}
{}
{}
{1,1}
(10 rows)

From what I understand of GIN's internal workings, this is unfixable
because there is nothing to make an index entry on when looking at
an empty array. Unless you know of a trick to get around that,
we've got a problem here.

[ pokes around ... ] Oh dear, it doesn't work with intarray's
GIST opclasses either.

Do we have to document these operators as being not quite real
containment?

regards, tom lane