llSensorRayCollision: Performs a ray collision test agains world geometry and returns the 16 closest objects that the ray collides with. Ray could easily be specified w/ a vector.
llSensorSweptSphereCollision: Same as above, but uses swept-sphere (or maybe capsule) collision testing. (w/ vector and sphere radius)

When I say "world geometry" I mean "objects/prims". Although, it might be interesting to be able to see if a ray hits the ground. Maybe a llDetectedStruckGround or something similar could facilitate this.

I don't imagine that either of these calls would introduce a great deal of lag, and I also don't imagine they would be that hard to add. However, they would provide for quite a little bit of usefulness in creating automated scripts. Furthermore, I believe that a properly crafted specialized sensor call could generate less lag than the usual llSensor("", NULL_KEY, ACTIVE|PASSIVE, 96.0,PI) calls that are in just about every single script that uses sensor.

Just my $0.02

-Thordain Curtis

More generally it would make it far easier to monitor a sim without the use of MANY sensors and relay scripts.

This function should be able to return immediately.

int llGetNumberOfAgentsInEstate()
int llGetNumberOfAgentsOnParcel()
key llGetAgentInEstateKey(int agent)
key llGetAgentOnParcelKey(int agent)

Or:
int llGetAgentCount(int mode);
key llGetAgentKey(int mode, int agent);

with constants for mode:
AGENT_IN_ESTATE
AGENT_ON_PARCEL

That said, a monolithic list could be pretty unpleasant - I can envision scripts running out of memory because they picked up a list of 50 keys.

Perhaps implement this in an event. For example, llGetAgentKeys(int mode) could trigger a sensor event (or it's own event) with the data.

I guess a list would be the best bet then, with a delay to offset the creation of the list. If it comes to it one script could be made that fetches the list, and then feeds the entries into another script one at a time.