If a block device triggers a mdadm scan, for instance during a EBS snapshot attachment, without having a proper mdadm.conf, a random device number is chosen (usually /dev/md127) and the assembly will fail, with reports that the device(s) are busy.
The device number chosen will also then be set in mdstat, however by this time the script already has has confirmed the device number, which is normally in most cases /dev/md0.
To ensure this doesn't happen we're queueing udev events, letting the RAID create or the existing snapshot volumes attach, then querying mdadm for its UUID and device number and tee'ing it to mdadm.conf.
Once the RAID is in tact by means of creation or assembly, we're safe to start the udev message queue and finally we update initramfs to be sure the configuration persists reboots.
This has been testing on ubuntu 12.04 in both a RAID10 and RAID0 configuration, and also with a RAID10 and RAID0 ebs snapshot restore ensuring that the assembly method was called.