Hahaha yeah, go figure :D

@ eric you appear to have fixed the fatal error of the script bailing, but when enabling the services still the first user is taken:

obarun# 66-mods.sh boot-user@ elvira
obarun# 66-enable -t user-elvira boot-user@ elvira
66-enable: info: Enabled successfully: setenv-marian
66-enable: info: Enabled successfully: All-marian
66-enable: info: Enabled successfully: mount-run-marian
66-enable: info: Enabled successfully: scandir-marian

Hmmmmm.....
Thanks for the explanation.

Observations:
[1] Your proposed workaround needs to be # 66-enable -t user-elvira All-elvira to be found, as that is what the service is actually called in /usr/lib/66/service/boot-user@ elvira

# 66-enable -t user@ elvira All@ elvira
66-enable: fatal: unable to resolve source path of: All@ elvira

# 66-enable -t user@ elvira All-elvira
66-enable: info: Enabled successfully: All-elvira
66-enable: info: Enabled successfully: mount-run-elvira
66-enable: info: Enabled successfully: setenv-elvira
66-enable: info: Enabled successfully: scandir-elvira

# 66-intree user@ elvira
Name        : user@ elvira
Initialized : no
Enabled     : yes
Current     : no
Contents    : scandir-elvira-log mount-run-elvira setenv-elvira scandir-elvira All-elvira

[2] I did have quite some versions of those service directories.

• boot-user-marian (containing All-marian)
• boot-user@ marian (containing All-marian)
• boot-user@ (containing All-marian)

dbus service module broken

[3] This is a pretty recent fresh install with the plasma template from the latest ISO with updated themes. There's some serious flaw in here and it is not having several named directories, let me tell you a story:

As always I was like: Let's play around with this (why the f*** do I always decide to do this on my production environment...?)...
I renamed the old version directories to include BAK and recreated everything as it is supposed to be:

# 66-mods.sh boot-user@ marian
# 66-tree -nE user-marian
# 66-tree -UR boot-user
# 66-enable -t user-marian All-marian

Well now I had all the setenv etc. enabled successfully on tree user-marian but after a reboot dbus wouldn't synchronize anymore...
Man, I'm one of a lab rat...
So I thought I could recreate the old configuration, so I renamed the original folders and recreated boot-user

# 66-tree -nE boot-user
# 66-tree -UR user-marian
# 66-enable -t user-marian All-marian

Now I had all the setenv etc. enabled successfully on tree boot-user but after a reboot dbus wouldn't synchronize anymore...
༼ ༎ຶ ෴ ༎ຶ༽
You know what? I have never been successful in establishing the modules from ground up with a minimal install as outlined in the Wiki/when it came out. And I tried quite a few times.
So for the recent installs I just used the plasma template, and if I wanted a minimal install I removed all the plasma packages because I knew that at install time the modules are configured in a way that they'd work. Where's the difference in the commands the template uses and the Wiki?

So I've got some down time on my work station for now (⇀‸↼‶)

Follow up:
I'm currently comparing with the latest install (spoiler: 2006 laptop; plasma template with individually picked packages) and here the main user from the install script is rather on tree "username-session" and in addition there is absolutely no specifically named service directory for that user. So it appears to me that the template creates /usr/lib/66/service/boot-user@ containing all services for the user created from the install script like "All-username" and then enables those on top of "username-session".

But even so, if I try to do this manually then it just plain won't work. I tried to mimic this on my main rig and renamed /usr/lib/66/service/boot-user@ marian to /usr/lib/66/service/boot-user@ and enable them on top of tree "boot-user" (just as before) and it still won't sync.

The concept is great, and it works great as long as it is for a single user from an install done with a X theme template and not playing around with it afterwards.

By the way something I have noticed in the past: I have played around a lot with trees generally speaking and I have found that in the past certain services and trees wouldn't get flushed well so to say. That means that I have found out that in some instances there would be left overs of tree names somewhere in 66 or services not really disabled when deleting a tree and so on. I can not find any such thing currently but I remember very well that this was an issue in older 66 versions.

Nice eric, you know where your configuration files are located hahaha XD
Ok, so that's a note I'll make a sticky to my wall: When completely deleting services, also check the users .66/conf for the corresponding config files and directories.
Thank you.

The second user would still not work though. I recreated several times the trees, services (root and user) and checked for all directories we mentioned by now.
~/.66/conf/boot-user/boot-user@ username will always be populated successfully with the necessary dbus environment variables.
~/.xsession is identical for any username
the root tree of "user-username" is successfully populated with the necessary services
the user tree of "dbus" is successfully populated with the dbus user service
"username" will not be able to sync dbus though.
The main user can log in nevertheless.

Solved!

For everybody (this is regarding the dbus module script specifically):

1. Create a new user from within your system settings, let's call him/her NEWUSER (this was tested on Plasma, it would be nice to have somebody check this for Xfce)
2. Log out and change to a console terminal like tty1, tty2 or tty12 depending on your setup. tty12 will always work but you'll have to log in as user and then su into root.
3. Log in to a tty as root
4. Create the dbus services for the new user using the modules script:

   obarun# 66-mods.sh boot-user@ NEWUSER
   

5. Create a root tree to hold the just created services (you could enable them on any tree, like a centralized tree for all users)

   obarun# 66-tree -nE user-NEWUSER
   

6. Enable those services on the newly created root tree:

   obarun# 66-enable -t user-NEWUSER All-NEWUSER
   

7. Switch to the NEWUSER, create a new tree and enable the dbus user service on top:

   obarun# su NEWUSER
   [NEWUSER@ obarun ~]$ 66-tree -nE dbus
   [NEWUSER@ obarun ~]$ 66-enable -t dbus dbus-session@ NEWUSER 
   

8. Reboot (not optional)

This is basically what we have in the Wiki, but the typo needs to be corrected for "66-enable All-NEWUSER". The wiki uses "All@ NEWUSER" instead which will throw an error.

Yeah sorry I overreacted there XD
I actually edited those parts.
I have mentioned before that you don't need any Obarun services or modules to run KDE5 with xinit. It's a consolekit thing and needs the appropiate command line argument. But it's really nice that Eric found a way to have a working display manager, I do appreciate that.

(Surely you wanted to say "for awesome desktops like plasma [...]" :P )