S1: Having the players name and IP available in script would be a modders heaven.
S2: Ability to detect player key input, allowing me to check what keys he's pressing on his keyboard. Or maybe the other way around, checking to see if he pressed a certain button.
Would be a more efficient and extensive than executing scripts whenever he presses secondary fire or the forward key in the statefiles...
S3: Individual HUD elements. "huddraw_" commands offer the scripter 256 available and unique, new HUD elements to be drawn onto the HUD. Unfortunately, these are applied to every single player.
Options range from position on screen to colour, to shader, to font, to alpha, to virtualsize (making it appear at about the same position on different resolutions) etc...
Making individual HUD elements requires a workaround: stufftexting globalwidgetcommands which basically temporarily edit stock UI menus, which are then stufftexted to show. Problem is there are only 3 usable and hiding them happens slowly.
Adding several more would resolve the issue, but would make it clientside.
S4: Ability to read player config, or in other words: what cvar values he has set.
S5: Inventory detection. 1 property that contains every weapon he can switch to. Modelname is sufficient. Additionally, something that indicated which one of the weapons he's currently holding (if any).
Something that would also be interesting is the ammo he has for each of the 7 types (shotgun, bazooka, mg, smg, rifle, pistol and grenade).
S6: Forgetting the most important one of them all. Detecting the player's state. We can detect if he's alive or not. But the term 'alive' isn't what it seems. If a player is in spectator, he is 'alive', even if the player has chosen a team, but not a weapon yet (thus he hasn't spawned), he is labelled as alive.
So what I propose is simple, a property telling us whether the player is spectating, dead (ie. not a spectator, but neither spawned, this is the one thing they got right though) or alive (spawned and not dead) or choosing (not spectating, not dead, and not spawned: he's choosing a weapon).
You can see a trend here? Why all my suggestions imply detection is because the $player entity as it is now, is a complete mystery to scripters. All we know is his coordinate position, his three-dimensional angle, his team, his health (which is as misleading as the 'isalive' command I talked about above) and his clientnumber.
We have to use our imaginations to find workarounds to some of the missing information but some things are just impossible to obtain.
S7: Adding kills and deaths. Adding a kill:death ratio to the scoreboard would also be a nice feature.
S8: Teamkill detect and punisher. 3 strikes and you're out kind of thing. Strikes can fade over time. All cvar set?
It is possible to detect the 'i-drop-nade-and-then-switch-team' phenomenon, even in script. I basically run a script from the grenade tiki files. In the new script the grenade is self and parm.owner is his owner. The owners current team gets saved along with a property indicating he has just thrown a grenade. When the nade explodes, it vanishes so self = NULL and then the script undoes the grenade property. Meanwhile another script gets run each time a player respawns. If that script detects that the player had just thrown a nade and his current team does not equal his previous team, followed by a sudden increase in kills, it is recorded as teamkill.
This reminds me to point out a weird bug in the engine. I detect kills by glueing a trigger set to spawnflags 128 (which will make the trigger respond to damage only), slightly smaller than the boundingbox of the player. Each time a bullet/explosion/bash triggers it, the player the trigger is glued to, is checked for death. If death is detected, the trigger will deactivate and the script concludes that parm.other (origin of the last detected damage) is the killer and he receives +1 kill. This is not the problem, it works beautifully. The problem is when a bullet flies through a trigger set to damage (spawnflags 128 and all combinations), it becomes 'bugged'. It suddenly is capable of flying through solid models and doors, sometimes even walls.
Not sure if you can ever find or fix this detail.