You'd need to implement an actual queuing or event system. The "wait state" mechanic just introduces an artificial lag/delay to processing the next command from the player; it doesn't actually pause anything at all.
The use I am talking about is for a forage command, Right now it says you don't find anything immediately and then waits, would be more realistic if it waited, then said you didn't find anything is all…I guess most muds just drops the realism there?
implementing an event system just for that seems like overkill
It's not overkill, because DikuMUD is designed to resolve all actions on each execution round. Without and event system to queue actions into future loop iterations, there is simply no way do do what you want to do.
Look at the code. All actions are done to completion, and all messages are printed to the output buffers of the victims. At the top of the next loop, output to players is actually sent, input from them is read and acted upon, and then autonomous systems are run.
You want delays, but you don't want a system that implements delays because it's overkill?
Well, you don't need a full event system just to implement foraging, however if you go down that path you will find yourself in the SMAUG boat and very rapidly regret your decision and wish you had taken the more general approach.
There's a port of the SocketMUD event system here. Though, I think it's based on an older version but either way, it's not a bad idea. As you get comfortable using it, you'll slowly be able to replace most of your *_update crap with events.