The same happens to me I just use UUID's to take care of it.

OK I'm back. Replaced a flakey disk, started over, created raid 1 (used metadata=1.2 this time had been using 0.90). Installed Slack64-current from Eric's 1.3.19 edition, copied over some scripts from my NAS and build latest kernel. Booted and it crapped out again, but some progress noted in that the fatal message about e2fsck not being found has changed from md127 to md0. So, some progress. Will try entering UUID in fstab to see it that works. Also noticed when building mdadm.conf that the raid is listed as /dev/md/0. Checked the last backup from my previously running -current and the mdadm.conf listed it as /dev/md/0_0. Does the metadata version make a difference in how the /dev/md is listed?

Edit: Noticed something else strange. The raid suddenly started rebuilding itself. If I do -

file -s /dev/md0

/dev/md0: Linux rev 1.0 ext4 filesystem data, UUID=318fbe83-55e7-452e-b27b-e4acfafa20e4 (needs journal recovery) (extents) (large files) (huge files)

but this UUID is very different from -

mdadm --detail --scan /dev/md0

ARRAY /dev/md0 metadata=1.2 name=slackware:0 UUID=f80a1f11:1a0802bc:7ef257d5:87f46ad2

This too is disturbing -

mdadm --examine /dev/md0 | grep UUID
mdadm: No md superblock detected on /dev/md0.

Finally got it working. Created /dev/md0 array after switching back to metadata 0.90. After rebooting everything runs fine but it still insists the array is md127. I don't care as I have the UUID entered in fstab so it can call itself what ever it wants. Thanks again to everyone for your ideas and suggestions.