Anyway I think we're in 2013 we have broadband and quad core, I'll wait for player reports
This is nice and all but if this is really going to effect things that much then is it really worth it? I don't even think changes like this are even necessary .
If you want a server with more LoS checks in different area (Mob Brain, Aggro checks, Pets Always checking LoS, Ranged Mob not shooting through walls, and at last PvP low latency...) you could easily flood the previous Methods without having any way to ponder LoS checks based on pendings checks right now...
As I see in Code the LoS checks are just limited to 10 at once in some part of the code, and the Server Properties (like 1 Los by player every 5 secs) have nearly no effects on all the server los checks, even property like "alway check pet los" wont have much effect when a pet cast spell, as spellhandler will do this los check without obeying server properties...
Now there is a main class LoS manager that knows every los checks queries, pending, finished, when they were made, what was the results, etc...
The heavier part of the code on server side come from all the LoS checks Manipulations (dual cache, contamination, cleanups, bestplayer query), but now that there is some caching and some "previous" data, you can use function like "LosCheckMgr.IsAvailableForLosCheck(player)" to take your own solution withing brains or spellhandler,
And if this code is heavier for a low number of player or low LoS check number, I expect it to scale rather well, the more there is player and Checks the more there is cache and distribution of LoS checks accross players.
Also, you can now code stupidly a new Script with a lot of LosChecks Queries without needing to think yourself how to throttle or cache (or even don't care at all when you don't have skills to do this...), you can put this in a short Loop, the Manager will try to do the less checks possible ! (And I intend to use this for new Mobs Brain which won't care the number of LoS checks they can handle, they will just query them or read cache)
At last my "Quad Core" comment was for Client Side

I don't know if it costs a lot to the Client to cast more than 10 ray tracing by second, but since the age of DAoC I expect player have above needs hardware !
It's an exercise in programming and understanding, and will be protected via a server property. IMO it's worth it asl long as the older faster system remains in place. Too few people have delved into the LOS stuff, we need more information.

As I needed to have my proper callback in packetLib I made it in a way you can use both method without having even crosstalks !
And Both methods can share a same result

(when a LoS result is receive it notifies old callback AND new callback !)
I have many "const" which can alter LosMgr behavior (setting radius to 0 prevent contamination, cache lifetime, cleanup loops can be configured, retrying loop too, range threshold) this will make about 10-15 new server properties
And each code using old callback need an explicit update to use new LosMgr (as it does much work that some Methods were trying to do, like finding a player owner to Pets for los checking, or Checking the max number of current LoS checks on this player)
To have a switch between old and new callback we would need to update Classes code with both new and old way, for now you're right it's more a programmer tool

(I'm replacing callbacks actually but I won't Commit it to Trunk like this !)
For Proof of Concept, on my shard All Mobs and Players uses new callbacks, All KeepGuards still use old callback, no problem with that and Shard's Custom Scripts will still be able to use them without updates.