With all due respect, I don't, since if we use a bitfield number for
flags, we only get 32 (or possibly 64) possible contexts, which also
require a centralized place for registration. I was hoping on using
the text-based contexts for extending the protocol as well. For
example, if a specific client implementation has some extra command
that it wants to use, it could request an extra context named
"myextension" or similar from the hub/peer, and if the request is
successful, then those commands will be available.

So you see, I was also planning on having the context scheme double as
capability arbitration. Don't you think that's even slightly good?

we can also use a mix of both solutions. Having some standard values defined in the protocol like:

base     0
identify 1
auth     2
main     4
operator 8

and allow both "auth|identify" or "2|1" or "3". This allows non standard extension to be coded like "myextension|3" (more compact than "myextension|identify|auth" but still understandable by clients not supporting the extension).

Eric