The use of scratch registers and macros in TeX/LaTeX date back to the time when it was absolutely essential to conserve memory consumption, because TeX's memory (both in terms of token/macro memory as well as number of available registers) was very limited and one could easily run out of space just by loading a few packages on top of the main format.

Traces of this can be still found all over the place in the code, e.g., you see things like \@plus as an abbreviation for the 5 tokens plus so that each time this was needed in code you would save 4 tokens. The same is true for registers which were limited to a total number of 256 of each type and loading, say pictex could already get you close to the total limits in available count and dimen registers.

However, using sratch registers and macros to overcome these limitations always came with a price: there is always the danger that the register or macro got reused while your code is still assuming that it holds your value! And despite a lot of precautions (like using them only within a group or ensure that setting and use would be really really next to each other) time and time again it caused bugs and issues because macros got called within arguments of others (both assuming that they could safely use the same scratch object) or through the fact that the output routine is visited in unexpected situations changing the context.

With LaTeX2e which was born 1994 or so the size limitation got even worse because the core code got extended. So we had to use scratch registers all over the place and conserve memory as best as we could. But knowing the issues with them we split the scratch registers into two: those that we wanted to see only being used within kernel code and those that had been used in the past by third party packages already (and which we couldn't take away without breaking those package). Therefore we introduced \reserved@... hoping that the name clearly indicates that they are not intended for use by package authors.

Bottom line: use of scratch registers and macros is not advisable unless there is a very good reason and these days the original reason (the memory limitation) is no longer valid. All modern TeX installations (younger than a decade or so) these days are based on eTeX and all offer enough space and registers that it is much better and simpler if packages use their own private commands and registers and therefore can rely on living side by side without any headache.

With LaTeX3 (expl3) we recomment not to use any scratch registers at all even though we do offer a few as we know that old habits do not die easily.

The use of scratch registers and macros in TeX/LaTeX date back to the time when it was absolutely essential to conserve memory consumption, because TeX's memory (both in terms of token/macro memory as well as number of available registers) was very limited and one could easily run out of space just by loading a few packages on top of the main format.

Traces of this can be still found all over the place in the code, e.g., you see things like \@plus as an abbreviation for the 5 tokens plus so that each time this was needed in code you would save 4 tokens. The same is true for registers which were limited to a total number of 256 of each type and loading, say pictex could already get you close to the total limits in available count and dimen registers.

However, using scratch registers and macros to overcome these limitations always came with a price: there is always the danger that the register or macro got reused while your code is still assuming that it holds your value! And despite a lot of precautions (like using them only within a group or ensure that setting and use would be really really next to each other) time and time again it caused bugs and issues because macros got called within arguments of others (both assuming that they could safely use the same scratch object) or through the fact that the output routine is visited in unexpected situations changing the context.

With LaTeX2e which was born 1994 or so the size limitation got even worse because the core code got extended. So we had to use scratch registers all over the place and conserve memory as best as we could. But knowing the issues with them we split the scratch registers into two: those that we wanted to see only being used within kernel code and those that had been used in the past by third party packages already (and which we couldn't take away without breaking those package). Therefore we introduced \reserved@... hoping that the name clearly indicates that they are not intended for use by package authors.

Bottom line: use of scratch registers and macros is not advisable unless there is a very good reason and these days the original reason (the memory limitation) is no longer valid. All modern TeX installations (younger than a decade or so) these days are based on eTeX and all offer enough space and registers that it is much better and simpler if packages use their own private commands and registers and therefore can rely on living side by side without any headache.

With LaTeX3 (expl3) we recommend not to use any scratch registers at all even though we do offer a few as we know that old habits do not die easily.

The use of scratch registers and macros in TeX/LaTeX date back to the time when it was absolutely essential to conserve memory consumption, because TeX's memory (both in terms of token/macro memory as well as number of available registers) was very limited and one could easily run out of space just by loading a few packages on top of the main format.

Traces of this can be still found all over the place in the code, e.g., you see things like \@plus as an abbreviation for the 5 tokens plus so that each time this was needed in code you would save 4 tokens. The same is true for registers which were limited to a total number of 256 of each type and loading, say pictex could already get you close to the total limits in available count and dimen registers.

However, using sratch registers and macros to overcome these limitations always came with a price: there is always the danger that the register or macro got reused while your code is still assuming that it holds your value! And despite a lot of precautions (like using them only within a group or ensure that setting and use would be really really next to each other) time and time again it caused bugs and issues because macros got called within arguments of others (both assuming that they could safely use the same scratch object) or through the fact that the output routine is visited in unexpected situations changing the context.

With LaTeX2e which was born 1994 or so the size limitation got even worse because the core code got extended. So we had to use scratch registers all over the place and conserve memory as best as we could. But knowing the issues with them we split the scratch registers into two: those that we wanted to see only being used within kernel code and those that had been used in the past by third party packages already (and which we couldn't take away without breaking those package). Therefore we introduced \reserved@... hoping that the name clearly indicates that they are not intended for use by package authors.

Bottom line: use of scratch registers and macros is not advisable unless there is a very good reason and these days the original reason (the memory limitation) is no longer valid. All TeX installations these days are based on eTeX and all offer enough space and registers that it is much better and simpler if packages use their own private commands and registers and therefore can rely on living side by side without any headache.

With LaTeX3 (expl3) we recomment not to use any scratch registers at all even though we do offer a few as we know that old habits do not die easily.

The use of scratch registers and macros in TeX/LaTeX date back to the time when it was absolutely essential to conserve memory consumption, because TeX's memory (both in terms of token/macro memory as well as number of available registers) was very limited and one could easily run out of space just by loading a few packages on top of the main format.

Traces of this can be still found all over the place in the code, e.g., you see things like \@plus as an abbreviation for the 5 tokens plus so that each time this was needed in code you would save 4 tokens. The same is true for registers which were limited to a total number of 256 of each type and loading, say pictex could already get you close to the total limits in available count and dimen registers.

However, using sratch registers and macros to overcome these limitations always came with a price: there is always the danger that the register or macro got reused while your code is still assuming that it holds your value! And despite a lot of precautions (like using them only within a group or ensure that setting and use would be really really next to each other) time and time again it caused bugs and issues because macros got called within arguments of others (both assuming that they could safely use the same scratch object) or through the fact that the output routine is visited in unexpected situations changing the context.

With LaTeX2e which was born 1994 or so the size limitation got even worse because the core code got extended. So we had to use scratch registers all over the place and conserve memory as best as we could. But knowing the issues with them we split the scratch registers into two: those that we wanted to see only being used within kernel code and those that had been used in the past by third party packages already (and which we couldn't take away without breaking those package). Therefore we introduced \reserved@... hoping that the name clearly indicates that they are not intended for use by package authors.

Bottom line: use of scratch registers and macros is not advisable unless there is a very good reason and these days the original reason (the memory limitation) is no longer valid. All modern TeX installations (younger than a decade or so) these days are based on eTeX and all offer enough space and registers that it is much better and simpler if packages use their own private commands and registers and therefore can rely on living side by side without any headache.

With LaTeX3 (expl3) we recomment not to use any scratch registers at all even though we do offer a few as we know that old habits do not die easily.