I think you may be confusing what happens in a process and in a behaviour.

A process consumes messages using receive. Unconsumed messages are left in the process message queue until they are consumed with a receive, they never go away by themselves. message_queue_len returns the number of messages currently in the message queue. The system does not keep count of the total number of messages that have arrived to a process.

Note that there is no default handle_info or equivalent for a process.

The generic code in behaviours generally have a top-level receive loop which processes every message it finds in the message queue. Through the format of the message it knows which callback function to call to process the message. The handle_info callback is the one which is called when and unrecognised message arrives, one that hasn’t been sent with a call or a cast nor is an OTP system message. This is something which is handle by the behaviour so the message queue will never be allowed to build up.

The behaviour does not keep count of the total number of messages which has arrived at the process but it does keep count of the number of messages which it has processed in the top-loop. You can query this using :sys.statistics/2 to query the behaviour. Note that this is implemented by the generic behaviour code and is not not something that is implemented by the system for all processes.

A final note. The basic concurrency model in Erlang and Elixir is very very simple and is based on four main ideas: isolated processes, asynchronous sending of messages, selective receive, and timeouts in the receive. Everything else, for example how behaviours behave, is explicitly built on top of this.

Sorry this became a bit longer than planned. I hope correctly understood what you were asking about.