CHECK_KEYSERVER semantics need re-thinking
currently, CHECK_KEYSERVER can be set to true, false, or left unset.
If it is unset, it defaults to "true", except for the @ssh-proxycommand@ subcommand, which has a much more nuanced default based on the presence or absence of matching keys or user IDs in the local keyring and known_hosts file. Setting it explicitly to @true@ or @false@
It turns out that we might want similarly nuanced defaults for @monkeysphere keys-for-userid@ (see #1997 (closed)).
I worry that seems like it has become difficult to even describe the semantics of CHECK_KEYSERVER as we're exposed it to the user. Can we re-formulate it to be simpler somehow?
(from redmine: created on 2010-03-14)