You could run it in the user session via sshd but we decided not to turn it on by default. The problem is there is no session management cabability to prevent multiple ssh logins creating multip restorecond -u sessions.

So if I understand it correctly, the following part of man page is not true, when running by user himself or sshd:
"Uses dbus to make sure only one restorecond is running per user session."

The thing is that when users log in via ssh and create files and dirs in home directory, they'll get wrong contexts. This is not true for RHEL5 or RHEL7 and it can be confusing. And since the correct filesystem labeling is the precondition of correct selinux performance, it seems like an issue to me.

And what was the reason to split restorecond comparing the single restorecond in RHEL5?

ssh sessions do not start a user dbus session,so

"Uses dbus to make sure only one restorecond is running per user session."

Does not apply.

RHEL5 is the same, except we did very little labeling in the users homedir.

Other then ~/.ssh what directories are you worried about?  I guess public_html.

Yes, public_html, but I was mainly concerned about "~/*". I thought that it is necessary to assign correct context instead of inheriting user_home_dir_t.

No,  Files will be created with the default label of user_home_t.  We have a transition rule that says a user domain(unconfined_t) will create content in a directory labeled user_home_dir_t as user_home_t.

There are only a couple of directories/files which could get mislabeled, without restorecond -u running, and for the most part these never effect the normal user.

Ok. If so, I agree to close as wontfix.

Unfortunately...