Win10: Access other logged on users' memory

First, a bit of basics: users don't have memory, processes do. Usually these are user processes (such as Alice's Notepad.exe instance), but they can also be system processes (such as services or subsystems - like Local Security Authority Subsystem, LSASS.exe - which may span user sessions and have per-user memory). As you noted, an Administrator-level user ("admin") can list the processes of other users quite easily. They can do more than that, though: they can access those processes (or any other processes on the system, except for a few that are protected for DRM reasons) as though the processes were their own. This includes full debugging access (with read - and write, though that's not relevant here - access to the process' memory), and also enumerating the open HANDLEs (files, network sockets, registry keys, named pipes, shared memory sections, etc.). Admins also can access quite a lot of logging info on the system.

To answer your specific questions:

1. If Bob bothers to check, this is easy. He can look in the event viewer for security events like Alice logging in and then locking her session. He can look at files that Alice has open (by checking the HANDLEs of her processes) and see what their date-modified or date-accessed timestamps are (even EFS-protected files still expose metadata like timestamps).
2. Currently-running programs are very easy (Task Manager, tasklist.exe, Powershell, Resource Monitor, etc.). In fact, it's almost hard to miss if he uses any of those programs. Programs that Alice closed recently are harder, but still possible; they may have Event Log entries, they may have modified data files that only they would have reasonably used, and their date-accessed timestamps on the binaries will be updated. Bob would have to go looking for those, though, rather than them just falling into his lap the way her currently-running processes would.
3. Same as #2, really. Knowing the exact times a program that is no longer running was started and stopped might be hard, but he could get some point when it was running just by checking timestamps on the right files, and possibly more info by looking at system or app-specific logs (assuming the app-specific logs aren't encrypted).
4. For processes that are still running, enumerating their open HANDLEs is easy. Several built-in programs can do it (for example, Resource Monitor), as well as common free ones such as Process Explorer. Sorting that list by file path, and looking for the paths that lead to Alice's encrypted directories/files, is easy enough.
5. This is trickier, though still possible. Using a debugger (such as the free WinDbg or Visual Studio Community Edition from Microsoft), you could definitely read the process' memory, but knowing where to find the data you seek could be hard. An easier option would be inject a DLL into the process (you'd need to have written the DLL, or found one online, but anybody reasonably familiar with Win32 programming and with access to a compiler could do it in well under an hour) with a DllMain function that either reads the files you care about and writes them to an unencrypted location, or simply decrypts the files themselves (or grants Bob access to them; EFS files can support multiple users accessing them).

Reading from the pagefile or hibernation file is technically possible, but is usually something you would only resort to if the computer was turned off and its RAM held no data anymore. You would need to do a decent amount of forensic work to re-construct which blocks of memory were in use by which processes for what purposes. Much easier, if you want to do raw memory access like that (which is basically what those files are, raw memory written temporarily to disk, though only incompletely in the case of the pagefile) and don't have a specific tool for finding the data you want (which you could write, but it would take a lot more effort), to use a debugger that lets you query the running system and its processes in real-time.

Taking ownership of the processes isn't actually needed; admins have debug-level access (and edit-permission level access) to all processes by default, and can (with only moderate effort) ignore the ACLs of any process (or file, or other securable object) at will. They can also take ownership of any securable object, at which point they can edit its ACL and then, if desired, set the owner back to the original owner and even restore the original ACL; so long as the admin (Bob) opened a HANDLE to the process with the desired permissions while he had given himself access, he can access the process' secrets via that HANDLE even after restoring the original access. Note that taking ownership of the process merely changes who controls access to it and some other details; it does not change the Session or Window Station of the process' windows, which means you can't move those windows onto your desktop.

One way that you didn't mention, but that deserves mention, is simply extracting Alice's EFS key, or even her password, from the running system. Since she is still logged in, her credentials will be stored in memory. The most common tools for extracting them are Mimikatz and Cain & Abel. On Win10, it is possible to protect the memory used for storing the passwords in a way that defeats typical use of Mimikatz, but this is neither the default configuration on most systems (especially home ones) nor a foolproof protection against, for example, forcing one of Alice's running programs to just export her EFS key (which can be done using standard Windows APIs, though you might need to write a DLL that calls them yourself). If you get Alice's credentials, you can then use them to log into her still-running session (through the Login screen, or over the network via Remote Desktop Protocol) and take over her session that way.

Also, if Bob is a sneaky sort, he could change Windows so that users' passwords are stored under reversible encryption, and then just decrypt Alice's password. He would have to wait for her to log in again - changing that setting has no effect on users until they log in - but he could do it if he accessed the computer subsequent to changing the setting and then letting her use it (and she didn't change it back). Alternatively, he could simply install a keylogger to record Alice's passwords.

Long answer above.

If they are both in the administrator group then they have the SeDebug permission which allows them to attach to processes for debugging purposes. So they can inject code into any process, pretty cool right?

Or they could just dump the memory of the process via TaskManager or Powershell that is being run by the other user and then SysInternals strings - or view that content with Process Explorer.

As they are both administrators they can even TAKE over the previous users sessions if that user has left the session logged on using tscon (If running as system - which as an administrator you can do with psexec).

With Administrator on a machine - all processes and data can be viewed one way or another. Be it dumping memory, debugging or installing programs to run under other users accounts.