Custom geometry, why slow?

The story so far ... The provide polygon@>point routine does not work
correctly when the points are close to the boundary. So we implemented a
custom contains(poly,point) function. In order to stop all points being
checked against all polygons, a separate bounding box is maintained. So
the query has sections looking like :

boundbox @> box( thepoint, thepoint ) AND
contains(boundary,thepoint)

You will notice that each point to be checked has to be promoted to a
degenerate box. Working on the assumption that there is a cost
associated with this (ie pmalloc), and we will be passing 100's of
millions of points though this in a single transaction, streaming this
is important. At any rate it looked kludgy. The goal is provide :

boundbox @> thepoint AND
contains(boundary,thepoint)

So the whole family of "point op box" functions where provided (except
for point <@ box) which already exists. The operators have been created.
And the operators added to the box_ops operator family. Samples below :

CREATE OR REPLACE FUNCTION leftof(box,point) RETURNS boolean
LANGUAGE C IMMUTABLE STRICT
AS 'contains.so', 'box_point_leftof';
..etc...

DROP OPERATOR IF EXISTS <<(box,point);
CREATE OPERATOR << (
LEFTARG = box,
RIGHTARG = point,
PROCEDURE = leftof,
RESTRICT = positionsel,
JOIN = positionjoinsel
);
...etc...

ALTER OPERATOR FAMILY box_ops USING GiST ADD
OPERATOR 1 << (box,point),
OPERATOR 2 &< (box,point),
OPERATOR 3 && (box,point),
OPERATOR 4 &> (box,point),
OPERATOR 5 >> (box,point),
OPERATOR 7 @> (box,point),
--OPERATOR 8 <@ (point,box),
OPERATOR 9 &<| (box,point),
OPERATOR 10 <<| (box,point),
OPERATOR 11 |>> (box,point),
OPERATOR 12 |&> (box,point);

The problem is, according to EXPLAIN, it still wants to do a sequential
scan and not use the index. Any pointers as to why?