When the volume is mounted without specifying the fs type, then one
obtains:
sh-3.2# mount /dev/mapper/VolGroup00-LogVol02 /home
mount: unknown filesystem type 'ext4'
This seems to imply that the fs is labeled or recognized as "ext4" whereas
it used to be handled as "ext4dev". The issue it thus probably due to some
inconsistent use of the fs identifier.

blkid recently changed... as did the kernel... welcome to the bleeding edge :)
In short, install e2fsprogs-1.40.5 from rawhide and run "tune2fs -E test_fs
/dev/mapper/VolGroup00-LogVol02" and it should be happy. If not please reopen.
2 things here; the kernel code rejects the mount if test_fs isn't set, to try to
be sure we don't accidentally claim ext3 filesystems, as well as to put a bit of
an intentional barrier to premature use into place. :) If you look at "dmesg"
after the failed mount (as the mount command suggests...) it will say:
+ printk(KERN_WARNING "EXT4-fs: %s: not marked "
+ "OK to use with test code.\n", sb->s_id);
Perhaps that should give more instruction about the tune2fs command to use.
Also, blkid now reports "ext4" instead of "ext4dev" if the test_fs feature isn't
set, so it tries to mount as ext4 instead of ext4dev. That's what you saw with
the bare "mount" command.
Technically this is not a bug, but rather design, but it is unexpected. Sorry
about that.