[standardUser]

It's not clear to me why the clicker can't beep to confirm instead of the car itself!

I guess it's just for finding your car in big parking lots? Seems like a different button could be dedicated for that far less common use case.

[Yetanfou]

That's simply because these remote controls are transmit-only, fire-and-forget devices which spew out a pseudo-random code to the receiver without being able to listen to any response. This is also why you should not click the button on the remote too often (as in 'more than 255 times') when not in range of the car as that gets the transmitter (key) and receiver (car) pseudo-random generators out of sync - the receiver accepts a sliding window of 256 random codes as valid. There might be different implementations of this feature using key fobs but this describes the majority of them.

[Deimorz]

That requires the car to communicate back to the clicker, which is more difficult/expensive, and can fail even if the car did successfully lock.

It's certainly possible though, these are usually called "2 way remotes": https://www.compustar.com/what-is-2-way/

[markdown]

In my car, the headlights and park lights flash once on every lock. No beep needed.

[shawnz]

AFAIK the fob is normally just a transmitter, so this would require it to also have a receiver in addition to a buzzer and other circuitry. I imagine that could significantly reduce the battery life.

[irq]

The solution you propose requires 2-way communication with the car. Virtually no cars do this (in their OEM configuration anyway.)

Without 2-way communication, the remote has no way of knowing if the vehicle acted on the signal.

[VMG]

I think the clicker can only send, not receive