I realize I never wrote down much about the internals of the back end in
detail, so here are some notes:

- This backend supports all features of Gnus which (I think) make sense.
- It is separated into three main parts - a set of parsing functions
  specific to Atom, a fairly generic implementation of server data
  storage (since most Atom feeds only contain the few most recent
  articles), and a Gnus back end interface which uses the former two
  parts to get information for Gnus.
  The intention is to allow creating inheriting back ends for different
  types of feeds by only changing the first part (and all of its
  functions are therefore stored in server variables).
  This also means a user can customize the parser by customizing the
  select method, which is pretty cool.
- The function responsible for printing the content of each part is also
  stored in a server variable ('nnatom-print-content-function).
  This means that 'nnatom-read-links-function' can return any Lisp
  object and 'nnatom-read-parts-function' can return any Lisp object as
  its car and any Lisp object in its cdr (a list) with a custom value of
  'nnatom-print-content-function'.
  The reason it is customizable is that Atom feeds only support plain
  text and (X)HTML feeds, and they already require some extra work to
  display nicely; I suspect if other web feed formats support other
  types of content they would also require something like that.
  And of course it can also be customized through the select method.
- A macro is provided which eliminates most of the boilerplate code
  required to define an inheriting back end.

I've also attached a simple inheriting back end for youtube channel
feeds - they are very slightly different from normal Atom feeds so it's
a good way to know whether issues come from the back end itself or from
the inheritance mechanism.

Regards,
Daniel