Forcing /home (or whatever useradd defaults to) into prefixes can have
a very bad side effect if your actual home dir roots are subdirs of
/home.  You end up with file contexts such as:

/home/foo               -d      system_u:object_r:home_root_t
/home           -d      system_u:object_r:home_root_t
/home/foo/[^/]+         -d      system_u:object_r:user_home_dir_t
/home/[^/]+             -d      system_u:object_r:user_home_dir_t
/home/foo/[^/]+/.+                      system_u:object_r:user_home_t
/home/[^/]+/.+                  system_u:object_r:user_home_t

So you see, /home/foo ends up labeled as user_home_t, not home_root_t,
and things don't quite work as expected.

Sure enough, having a single /home/foo is easy, and you can simply
adjust useradd's default to match that, but if you have many, no
default would be appropriate, and you then have to be careful to never
choose a dir that has any home dir as a subdir.  In fact, if you have
home dir roots that are subdirs of each other, things get
unpredictable, since the order of the hash keys is unpredictable. 
They should be sorted from outermost to innermost to get the correct
behavior and, even then, you have to group all above entries per
HOME_DIR before all such entries for nested homedirs, otherwise you
get incorrect labels.

Version-Release number of selected component (if applicable):
policycoreutils-1.18.1-2.6

How reproducible:
Always

Steps to Reproduce:
1.Create a user with home in /foo/bar
2.Create another user with home in /foo/baz/bad
3.Update file_contexts

Actual Results:  /foo/baz will have conflicting rules.

Expected Results:  They should be ordered properly, so as to be
predictable.