A pretty good idea, seconded, though I'm not sure how feasible that would be. Anyway, it would be much better fitted differently though, with a different name and on /world, which is more suited and is in the pattern (unless they'd actually make it modifiable per-player, in which case it'd need to be on /client). world.command_lag or as such would be a far better name.

Talking specifically about your sentence and the nature of the request, you are incorrect.
At the moment, a client can only send one command (which in turn invokes a proc or verb server-side) per tick. However, the server is perfectly able to process many commands (essentially, procedures) per tick.
So, at least technically speaking, the only thing that would be required to give clients the ability to send more than one command per tick is to "speed up the clients".

Or, more accurately, to just give them the ability to send multiple commands and have them accepted: whether the client is fast enough to send a command multiple times and have all those commands received by the server in a timeframe of one tick (one tenth of a second, by default) is entirely up to the client's connection [to the server]. It is probable that even with the default tick timeframe, even some people with good connections will not be able to do so, merely due to things like network jitter and their physical distance from the server.

Those work entirely differently, though. Essentially, the client just cheats in his local game and also cheats the server.
On the other hand, certain multiplayer online games do actually allow clients to customize the rate at which they send updates to the server, which is related to the topic at hand (however doesn't necessarily say anything as far as specifically discussing BYOND goes).

Very good idea. This is one aspect that I've always found annoying about BYOND. Not much incentive to work with advanced 2D collision detection or moving things off the grid if it all runs slow as crap.

Yes! This would surely be a great, GREAT help.

Android Data wrote:

Could there be a client.tick_lag value for commands only? Setting world.tick_lag to a value like 0.5 speeds up all the icon animations for the entire game. I would just like the client to be able to send more than one command per tick so I can implement features like "super speed running mode" without having to make walking slow as heck for everybody.

It might make more sense for us to speed up the client tick by default, based on what the server can reasonably handle (judged by network lag). A lot of the current limitations were written a long time ago, when we couldn't expect as much out of the network connections. I think we can do better.

Don't you think this might increase spamming in certain games that some people don't think are good for some reason(GOA). That might even crash some servers too, because if people are using macros faster and there's many people on, doing it at the same time.. Also if a developer doesn't think about the increased amount of commands allowed, they may end up getting spammed.
I'm probably so far off, but I think it'd be more reasonable to make a variable for clients(if possible).
Though, this is all based off of the thought that your not making a built-in variable for this.

I just had another idea. The set instant thing is nice, but what about a variable set at client-level that implements this for all mouse procs? That way, procs such as MouseEntered() and MouseExited() have little to no overhead when the network isn't strained and the user will have a seamless experience. Otherwise... eh, t'was worth a shot.