In gnus.user there was a longish conversation about how to better report
the failure of Gnus mail source fetching to the user.

I originally went off on a grand adventure of defining custom errors for
various kinds of Gnus situations, for use in flow control. I still think
that's a good idea, but `nnheader-report' currently does the core of
that job for backend-specific errors, and it's fairly well-developed,
and there's not necessarily anything that needs fixing there.

And the original bug report was more about making errors visible to the
user than flow control, so I went back to that. Apart from fundamental
backend errors, other errors and failures are surfaced with
`gnus-message' and `gnus-error'. Both are gated by the integer value of
`gnus-verbose': higher numbers indicate less-important messages.

The more I fooled with things, the more it looked like improvements
could be made in `gnus-error'. It does a few things:

- Calls `ding'. This function returns nil on my system, dunno if it does
  anything on other systems.
- Displays the error using `message'.
- If the error level is a float, it uses the "float part" as a number of
  seconds to `sit-for' while displaying the error message. So an error
  level 4.5 would (if `gnus-verbose' were 4 or lower) display for 5
  seconds.

So obviously the purpose of this function is to get the user's
attention, in appropriate situations. But `ding' doesn't seem to do
anything, and there are only three places in the Gnus codebase where
`gnus-error' is called with a float value. That means there are only
three places where the `message' isn't immediately swallowed by whatever
comes next (and there's almost always another message coming next),
which really means there are only three places where `gnus-error' does
anything different from `gnus-message'.

The point here was to alert the user to failures in a non-annoying way,
and I think the warnings facility might be a better way of doing that.
`delay-warning', in particular, with a custom warning buffer. The
attached is a code sketch of that. Some points:

- It's hard-coded to prevent buffer pop-up, instead letting the user add
  the buffer to Gnus' window configuration, or call an interactive
  command to see it. We could also do something like put a note in the
  mode-line when there are new log messages to view.
- I've referred to all this as "logging" rather than "warnings", as that
  seems more general.
- gnus-message can also add strings to `gnus-action-message-log', which
  is consulted at the end of startup and maybe displayed with
  `gnus-final-warning'. That only happens once, at startup; it seems
  like a complicated mechanism to only use once. I think this could be
  replaced by warnings.
- Actually I think both `gnus-message' and `gnus-error' could be
  replaced with a `gnus-log' function, but that's something that could
  be played with later on.

I think the main concerns here are making sure the user actually sees
important messages, through a combination of splitting them off into
their own buffer, so they don't get lost in *Messages*, and potentially
delaying display until a particular action is complete, and the user has
a chance to see them.