I think this is only an issue in cases where the data on the RAID device is also identically present in the same position on the underlying devices (or at least some of them). In practice that means the RAID formats where the RAID superblock (metadata) is at the end of the partition.
Since the UUID is part of the filesystem(*), the system must find a supported filesystem on the device first. Filesystems are identified by reading some set locations on the device, usually at the beginning, and looking for identifying signatures. If the same data is visible in the same position in a raw disk (like
/dev/sda) and a raid device (
/dev/md0) the same UUID can be found in two devices. Or more, if there are copies of the data on other devices, i.e. the other side of the mirror.
(* The UUIDs of GPT partitions are a different matter)
The Linux software RAID system knows of two main superblock formats, the original (v. 0.90) format puts the superblock at the end, and the current (v. 1) has three subformats for different positions of the superblock. Since the superblock formats 1.1 and 1.2 put the superblock in the beginning, they should be safe to use. 0.9 and 1.0 put the superblock at the end of the device, so they are the ones you can get into issues.
/proc/mdstat should show you the superblock format for each device.
The RAID wiki page also contains a warning about placing the superblock at the end of the device.
With RAID 0 or RAID 10 it's hard to read the filesystem through the underlying disks, since the data is striped. But the UUID's might still be detectable, so it's probably best to use the 1.2 format RAID superblock in
For ext2/3/4 filesystems,
tune2fs -l $device might be able to show you the filesystem UUID if it's possible to find (
blkid might find the RAID UUID instead.)
Note that I'm writing this based on my understanding of the documentation, I didn't explicitly test with a RAID superblock at the end.