The kernel doesn't load the initrd image, the boot loader does. You will still be able to boot from a software RAID set, as long as the bootloader can access the RAID volume and the set is assembled by initrd.

(And of course, hardware RAID is not affected.)

Apart from the already mentioned fact that the boot loader loads the kernel and initrd from the disk before the kernel even starts ...

RAID 1 is no different to a regular disk as far as file system layout goes, remember it is a mirror image nothing more.

You can try in /etc/fstab to use UUID= for /boot so this way it does not matter if /boot is on on /dev/sda or sdb etc, if it has that uuid it will boot.
lsblk -f to list uuids or tune2fs -l /dev/sdX in ext4 or ext3 ifle systems.

As for lilo.conf you can still keep the old way with raid-extra-boot with /dev/sdX,/dev/sdY entries.

Looking at the man page for lilo.conf, it seems that raid-extra-boot mainly deals with where the boot record will be written. I'm not sure how lilo would be dealing with being able to point to the kernel or initrd on *either* /boot partition - to cope with one hdd going missing. Actually, thinking about it, I'm not sure how lilo copes even at the moment with loading the kernel or the initrd off a /boot partition which sits on top of RAID 1. Clearly, I have to do more reading on this. The lilo.conf man page doesn't seem to shed enough light on how lilo copes with RAID 1. Also, I could be wrong, but the notes in lilo.conf appear to refer to the case of entire disks being array members - as opposed to having partitions as array members. For example they recommend using boot=/dev/md0 - but, if my understanding is correct, this would only work if /dev/md0 has entire disks as members, not partitions.

Given a RAID1 setup with 2 disks the correct use of this option will enable lilo to write itself to both disks so that when a disk is removed lilo will still be on the remaining disk.

The way lilo writes it's records to each disk is such that if the disks are different or have partitions in different locations each record is unique to the disk it sits on.

When a disk is removed from a computer the remaining disks are reordered in sequence, all lilo has to do is assume it is on the first disk and it will load.

So long as it is only RAID1 and a v0.9 superblock and does not have partitions inside the RAID device then lilo can create a sector map of the files it needs to load.

This is no different to booting off a non RAID device, it just has extra options to enable creating the extra boot records on the second and later disks in case of the first disk suffering a failure.

I should also point out that RAID is not designed to deal with data corruption on a disk only the total failure of a disk, data corruption can only be dealt with via backups.