Thank you for taking the time to reply to my proposal.
A process gives its “consent” to other processes to send it signals when it shares its pid.
Yes, that’s a good point. Most of my comments were about the original proposal, where you had to tag who sent the message. I do agree priority aliases do solve some of my concerns.
I do worry about the need to track how aliases go through the system to figure out which messages are a priority. On the other hand, you are right, I can simply manually tag all priority messages, and organize that in the code myself. Perhaps a recommendation to be added to the docs. 
Something else to consider is that both the original and the aliases proposal will likely require a combination of monitoring, linking, or supervision trees to be used with named processes. As you said, a process gives consent to other processes to send it signals by sharing its pid, and in many cases this is done by a registry. However, if you get the alias from a named process, store it in your state, and the process crashes, the alias is now dead, and your message will go into the void.
This means that the processes need to be linked, be part of the same supervision, or you need to monitor, making sure you retrieve a new alias somehow. This also has an impact on the design of priority ad-hoc messages, such as the system ones, if that’s ever desired. Of course, you cannot request a priority alias just in time, as that request itself won’t be a priority and you are back to square one. You can find alternative solutions, such as having the process store its alias on a ETS table during init
or have a process whose sole job is to forward priority messages, but that’s additional human and computer work.
The original proposal had a similar issue but in the other direction, the receiver had to monitor the callers it wanted to prioritize. I believe those issues do not exist if you put the “burden of proof” on the message itself. At the end of the day, both proposals want to prevent abuse, but one does so by choosing the messages and the other by choosing the sender.
EDIT: The above is not meant to be a blocker but mostly a disclaimer. It is clear this feature is for power users, so it is probably fine to assume they’d be familiar with the failure semantics and properties. 