I'm also confused about stuff I keep reading about 70-persistent-cd.rules getting auto generated. I thought maybe I need to regenerate that and edit it, but if I move it somewhere and reboot, it doesn't get generated.

I noticed that I in fact didn't have a few of those kernel options set...the block layer sg one and the devtmpfs. However enabling them didn't help, and I'm sure I never had them set in the past and had no issues.

I have three machines with the same problem, and I'm getting nowhere. I'm not clear when this changed, as I actually don't do a lot of things that require those links.

# This file was automatically generated by the /lib/udev/write_cd_rules
# program, probably run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line
# and set the $GENERATED variable.

No matter what I did, NONE of the above pci related entries would work. The only way I seem to be able to get my symlinks is with very simply entries like this, creating links based on the existing sr0 and sr1 names:

1. Yes, I also see that udev-171 does not regenerate persistent CD rules upon reboot.
I was about to try udev-189, but upon emerging it a notice appeared saying all persistent network and CD rule generation scripts were removed upstream. (!!) So apparently we need to write our own rules from now on anyway. I promptly gave up on udev-189 without even trying it.

2. I'm no udev rule expert, but I guess "ID_PATH" may be the culprit, even though its values for PCI bus and SCSI ID are correct. My fresh gentoo install had the following rules from somewhere.

I think the main idea though is that you don't want "sr0" to be in your match rules because that's not static/persistent. If the kernel decides to name your CD/DVD drive "sr1" instead (because it decided to call another CD/DVD drive "sr0"), the rules you have would break since "sr0" would no longer be on that devpath. As a result, you would have no cdrom, cdrw, dvd, or dvdrw symlinks (not even to the second drive that's now called "sr0" since the new "sr0" may not be on the same devpath).