What's broken with sensors?

Ok, what, precisely, is broken with sensors right now? I just built something to test sensors:

integer a;
list stuff;
integer yes;

default
{
    state_entry()
    {
        llSensorRepeat("","",AGENT|ACTIVE|PASSIVE|SCRIPTED,96,PI,2);
    }
    sensor(integer num_detected)
    {
        for(a=0;a<num_detected;a++)
        {
            if(llListFindList(stuff,(list)llDetectedKey(a)) == -1)
            {
                llSay(0,llDetectedName(a));
                stuff += (list)llDetectedKey(a);
                yes = 1;
            }
        }
        if(yes)
        {
            llSay(0,(string)llGetListLength(stuff));
            yes = 0;
        }
    }
}

And it's returning 16 objects per pass, but not the same 16 objects each pass, and it's not searching out as far as 96 meters. (EDIT: And now that I think about it, it never detected me.) I remember reading a similar thread on the same subject, but assumed it would have been fixed by now.

So what are the new 'rules' pertaining to this new sensor? Anyone know?

From my experience, the 16 objects you get are going to be a different 16 every time. They will usually be objects that are clsoe together in DB-space, but not necessarily related in game-sapce.

Really, any search that would return more than 16 hits should be taken as "undefined behavior".

My experience seems to indicate it will return the closest 16 things in sl space, in order, but so many people have said otherwise that I can't help but think I'm missing something. since you used the bitflags to indicate you want to return anything in it's scan radius, I have heard reports that a large number of possible results can return anomalous behavior. Try a sensor for each type maybe?