I think that what is going on here is this.
In most operating systems, including Windows, there are lots of data structures inside the kernel that the kernel "shares" between all the processes running on the machine. In early versions of Win32 (starting maybe with Windows 95?) there are some kernel data structures, specifically those having to do with the graphics device interface (GDI)) that are shared by all the processes that are using the same desktop. In early versions of the OS there was only one desktop, so only one session, so these data structures were just shared like all the others. In the Server versions of Windows each remote login gets a "terminal" which, I think, is sort of a virtual desktop. So now they needed to "virtualize" those GDI data structures inside the kernel that weren't previously virtualized. I think that a "session" is that set of virtualized GDI datastructures. They are shared by all processes running on the same "terminal", and each "terminal" has its own version of the data structures.
The reason this matters in the DataCollider paper you referenced is that they are using data breakpoints, which are set on virtual addresses rather than physical addresses. But race detection (in the kernel) really makes more sense from the physical address perspective. For most kernel data structures there is a one-to-one mapping from virtual addresses to physical addresses. You set a data-breakpoint on a particular virtual address and when it "fires" you know that the physical address corresponding to that virtual address is still the same. All processes, from all users, from all "terminals" are really sharing those data structures, and if there is a race, there is a race.
The problem, for DataCollider is that in "session memory" this one-to-one mapping doesn't hold. In the case of session memory the virtual addresses are the same for every process, but the physical address that virtual address is mapped to is different when the kernel is working on behalf of processes from different terminals. So when the data breakpoint fires you need to do some extra bookkeeping to figure out whether the virtual address is pointing to the same physical address that you intended when you set the breakpoint.