And before you ask: all this is a systemd-homed feature, it's not implemented for classic UNIX users (as systemd is not involved with managemen of them, and couldn't do the area management there), and it's unlikely it every will be. The user record extensions to make areas a thing are generic though.

And that's all for now.

… easily. I also want full access to all my data from each such VM to simplify my work. And the area concept allows me to do all that.

Note that while this 'virtualizes' $HOME and $XDG_RUNTIME_DIR nicely, it's not quite enough to run multiple full desktop environments in parallel for each user by giving them each an area of their own. That's because the per-user service manager only exists once right now, not in one instance per area.

In order to create such an area anew you can simply call "mkdir -p ~/Areas && cp -av /etc/skel ~/Areas/mynewarea". To remove it again just do "rm -rf ~/Areas/mynewarea" – you get the idea.

Of course, since all areas are owned by the same underlying UID, and associated with the same user record you can easily move around between the areas and the main home directory, via "cd" and similar.

The simple concept of areas can be used in various quite powerful ways.

…, as they want, and easily switch between them, simply by logging in specifying a user name of "username%areaname" at login time, when the system asks for a username.

This will primarily do two things: if you log in as user "foo" with area "bar" (i.e. specify "foo%bar" at login time), you end up with $HOME set to /home/foo/Areas/bar; it will also do something similar for $XDG_RUNTIME_DIR, to give your session a separate runtime directory.

But in various scenarios it is handy to have a single login account, but multiple home directories one can switch between, for example to maintain different configuration sets, or build environments, possibly for different hosts.

In v258 systemd-homed (and by extension the userdb logic) has a concept for maintaining multiple "areas" for each user account. Areas in this sense are simply subdirectories of the main home directory, below the ~/Areas/ hierarchy. A user can have as many of these, …

… which we can use similar to the AF_UNIX datagram timestamps.

So yikes, to properly synchronize on log processing, we need 4 different completel different mechanisms, and we have a lot of sockets to listen on. Uff!

But anyway, it's implemented now, and it works.

Enjoy your new "systemctl start -v"!