cc @thatcher-gaming, possibly of interest (no pressure)

This addresses some of #2274. One area where I am not satisfied is how the spec interacts with persistent clients ("always-on"):

1. I don't like the aspect of the current spec where it does an edge-triggered metadata sync on requesting the cap; I generally prefer explicit client commands to having CAP REQ trigger side effects
2. Instead, for always-on clients, we preemptively send them their own metadata in the registration burst, between 005 and RPL_ENDOFMOTD / ERR_NOMOTD. (In the spirit of the current spec, we might want to send even non-always-on clients that have requested the cap an empty batch here? Although if the batch is empty, you don't know what entity the empty batch is talking about --- really you need labeled-response even for a normal METADATA LIST command.)
3. For always-on clients, we would like to accept SUB during connection registration (since subs are per-session and they they take effect immediately after connection registration) but we do not necessarily want to accept SET, which could overwrite metadata that is more authoritative than the client's cached view
4. What is the use case for SET during connection registration for anyone?

I'm tempted to say that before-connect should take a value, either * for unrestricted or sub for subscription-related commands only.