SLIME automatically discovers how to indent the macros in your Lisp
system. To do this the Lisp side scans all the macros in the system and
reports to Emacs all the ones with &body arguments. Emacs then
indents these specially, putting the first arguments four spaces in and
the “body” arguments just two spaces, as usual.
This should “just work.” If you are a lucky sort of person you needn't read the rest of this section.
To simplify the implementation, SLIME doesn't distinguish between macros with the same symbol-name but different packages. This makes it fit nicely with Emacs's indentation code. However, if you do have several macros with the same symbol-name then they will all be indented the same way, arbitrarily using the style from one of their arglists. You can find out which symbols are involved in collisions with:
(swank:print-indentation-lossage)
If a collision causes you irritation, don't have a nervous breakdown,
just override the Elisp symbol's common-lisp-indent-function
property to your taste. SLIME won't override your custom settings, it
just tries to give you good defaults.
A more subtle issue is that imperfect caching is used for the sake of performance. 1
In an ideal world, Lisp would automatically scan every symbol for indentation changes after each command from Emacs. However, this is too expensive to do every time. Instead Lisp usually just scans the symbols whose home package matches the one used by the Emacs buffer where the request comes from. That is sufficient to pick up the indentation of most interactively-defined macros. To catch the rest we make a full scan of every symbol each time a new Lisp package is created between commands – that takes care of things like new systems being loaded.
You can use M-x slime-update-indentation to force all symbols to be scanned for indentation information.