If there's a limit, it's new and I can't find it in a quick search; I did find a 2014 PR that was rejected because dropping messages violates core semantics, IMHO killing the recipient would be OK though. Traditionally it's unbounded, but when you exhaust the memory of the host (or the ulimit, if set), you'll likely loose the whole VM.
EEP 42 is not implemented in mainline OTP. If it were, the proposal would likely link to the implementation, and the EEP index in EEP 0 would show what version it was first included in: https://www.erlang.org/eeps/eep-0000
If your application is using something like this, you're running a modified beam (which is fine; my professional experience is on a modified beam where we added a process_info option to drop all messages in the queue of a given process, and to allow for messages to be added to the front of the queue, neither of which would be acceptable upstream, but both of which were super handy for us)
