/etc/inittab as installed by the sysvinit package is not subject to config protection. If you reinstall sysvinit, congratulations, any customizations you've made are gone with no warning. If you install/upgrade sysvinit from a binpackage made with quickpkg's default settings, congratulations, you just replaced your inittab with a one-line apology for not having included the actual config file, and your system is now unbootable.
I tried to reproduce this on another machine and failed, so I did a bit more digging. I discovered the issue when attempting to use emerge with the --root parameter to repair a system which had ended up with the wrong cflags. At this point I strongly suspect that the overwriting occurred before I had gotten the system fixed enough to chroot in and continue rebuilding things normally. So, the question is how do --root and config-protect interact? I know that, during the process, it was respecting config-protect on the rescue filesystem because I was having to approve the changes for installing the build-dependencies, but the config files being changed were the ones in /etc/portage of the rescue filesystem. I'm guessing that when one uses --root to install the packages somewhere else the normal config-protect settings get left behind. If that is the case I would suggest that it should probably be changed to not do that since it ends up walking all over the configuration files with no backups.
