Btukfyl

The LaTeX kernel provides the 'scratch' macros @tempa, etc., and reserved@a, etc. These are used for a variety of purposes. Which should be used as temporary space by general users/programmers?

The reserved@... macros are reserved for use by the LaTeX team only: they should not be used by others. On the other hand, the macros @temp... are available for general scratch use.

This is because low-level parts of the kernel need to have reliable storage for internal use. The reserved@... series provide this, and using them may cause unexpected issues in apparently unrelated code. No such reliance takes place with the @temp... series.

If you are patching a kernel macro and using the reserved names exactly as the kernel does, you might of course need to use one. This is however an extremely limited set of circumstances.

LaTeX2.09 used @tempa, ... as scratch macros, but by the time LaTeX2e was being designed so many style files (packages) were using the same "scratch" macros they were not really "safe" any more so we used reserved@a,... in the format code, documented as not to be used by other packages. So @tempa and friends have no special status now, although they are commonly used because many common packages have a history that goes back to latex2.09 (ie before 1994).

But really for any package being written now there is no need to use these generic scratch macros at all. If your package is called wibble.sty use wibble@a, wibble@b,... etc.

In 1994, on a 640K PC running emtex there were only about 50 command names left after loading latex2e+amsmath, and so it made sense for as much code as possible to re-use the same command names. With a modern texlive or miktex installation there are typically several hundred thousand command names available in the string pool and obfuscating the code and running the risk of clashes with other packages by re-using some generic command names is probably taking a risk with no actual potential gain.

When writing code from scratch that might be used by people other than me, then I tend to write everything within an own namespace where each macro-name has its own prefix formed by the name of the project/package, trailed by an @ and an acronym denoting the person who wrote that code. E.g., for project foobar I don't use @tempa but I use foobar@UD@tempa. If I could easily use digits within names of control sequences, I would in many places include version number / date of submission into the namespace-prefix also.

Exception: Macro-names for macros for the user-level.

Besides this I tend to redefine whatsoever "scratch" macros not introduced by me within local scopes only, where at the moment of finishing producing whatsoever boxes, these local scopes are already closed again so that my temporary redefinitions don't interfere during moments where the output-routine is in action. (One can have fun in situations where globaldefs might have a positive value. ;-) )

Another issue are macros where hooks like everypar or everyeof get modified. Modifying somebody else's macros, e.g., scratch-macros from the kernel, might probably affect the way in which things triggered by those hooks are done. This in turn might cause problems.

E.g., recently there was a thread macros - inaccurate hyperlink to customly defined theorems where changing the kernel's box-register @labels happened even without the user being aware of that:

The labels of the text of a theorem-like environment were to be nested into another itemize-like environment. First the material for typesetting both the theorem-like environment's label and for placing an anchor for hyperlinks was placed into the box-register @labels. Theorem-like environments rely on everypar for typesetting the content of that box-register. But the content of that box-register was replaced due to the itemize-like-environment before the everypar-hook was carried out. This time with material where no anchor for hyperlinks was placed. Thus hyperref-functionality was broken.

So, problems with changing things belonging to the kernel can even happen without users knowing/intending that.