Beginning with the 2020.2 stack, the environment modules point to packages that were compiled with optimizations specific to the micro-architectures of the node type the modules are loaded on. This means that the binaries are not identical between different node types. The login nodes are different in that the modules loaded on login nodes will point to the lowest common micro-architecture. This means that if you use the module packages for development on a login node, the resultant binaries will run on all of the Argon node types. However, if you use the modules for development on a compute node, the resultant binaries will link against libraries built for the node type used, and may fail to run on less capable compute nodes. To avoid that, there is a stack/2020.2 module for the base architecture that can be used. If developing software on a compute node, load the stack/2020.2-base_arch module rather than the stack/2020.2 module. That will point to binaries of the base architecture and binaries linked to these will run on all compute nodes. That is assuming that no additional compiler flags were added during the compilation that would create host specific optimizations. Another reason that you may want to use the stack/2020.2-base_arch module is to ensure that the binaries used at run time are identical across different nodes.
For the 2020.2 stack, there were some issues with building R packages as separate packages so a single prefix installation of R packages was done for the 2020.2 stack. Those packages have been listed in a separate table below. There are a couple of exceptions though as the r-rmpi and r-snow packages are still separately loaded modules. The individual r packages can still be discovered with module spider and module avail as they are listed as module extensions. However, those packages will be loaded along with the r module rather than individually as separate packages.