If I read it correctly, the pulseIn() timeout includes the wait time for the pulse to start (ie, the low time if we're looking for a high) as well as the time of the pulse itself (ie the high time if we're looking for a high).
An improvement might be to have two separate timeouts... let's say for instance the start of the pulse depends on human interaction, while the pulse itself doesn't. Dropping coins in a vending machine for example, there would be long waits between coins, but the pulse itself as the coin falls through a sensor would be short.
So, how about:
pulseIn(pin, value, timeout1, timeout2)
where timeout1 is before the pulse starts, and timeout2 is the pulse itself?
In most applications it is preferable to use interrupts to be notified of external events as they happen rather than hanging around for pulseIn. The major limitation of pulseIn is that it can only watch one thing at a time, whereas interrupts can notify you of around 20 different events as and when they happen. To implement a timeout, you can easily track the time of the last event, if the time since the last event is too long, you know that you should enter a timeout condition. To take your example of a coin drop, the customer could equally press the cancel button, shake the machine to activate the vandal guard etc etc. Interrupts allow you to respond to all of these events the instant they happen.