Reading through this thread, I decided that there's an advantage to using a custom Birth Registration fact that had not previously occurred to me. That is, you could add the custom Birth Reg fact to the People View display, sort on that column, and make it pretty easy to identify which persons still should be researched. Don't know why that didn't occur to me before, because that's directly related to how I now document census data. Rather than record all census data in the default, built-in Census fact, I have created a custom fact for Census1624, Census1661, Census1681 .... Census1956 for every census year that I have in my database. While I still haven't converted all of my previous Census facts to my new Censusnnnn format, this will eventually let me create a custom report, and input that to Excel for processing and analysis in ways that lumping all that info under "Census" would complicate.
I do census the same way you do, and for the same reason. Which is to say, I have a custom census fact for each census year. Having done so, I can use the custom census facts as columns for People View, as columns for RM's custom reports, and as columns for my own custom reports with SQLite. But to tell you the truth, the technique is so powerful that People View is usually sufficient and I don't have to resort to RM's custom reports or my own custom reports with SQLite very often.
Tom created an SQLite script to convert RM's built-in census fact to custom census facts of the form censusnnnn so I didn't have to do it manually. Well, I did have to change the sentence templates manually, but that was very easy as compared to changing all the census facts for everybody in my database.
It's a very useful and very general technique. For example, I only enter one birth fact for each person and I store conflicting birth information in the birth note. But it's an entirely reasonable approach to enter multiple birth facts for a person, one for each possible conflicting birth date for the person. RM doesn't handle duplicate facts very gracefully for searching, People View, etc. So instead you could have custom birth facts called birth2 and birth3 or something like. If you did it that way, you could make your birth2 and birth3 facts into columns to find people with multiple "birth" facts in People View, you could use them for color coding or creating groups, etc. It's a very powerful technique.
For another example, I created a custom fact for City Directory, but I have converted such facts to separate custom fact types, one for each city directory year. So I can use these custom City Directory facts for each City Directory year to create columns in People View and to find people with missing City Directory data. People View is a powerful, powerful, powerful tool if used to its best advantage. And it's even more powerful because it can be filtered by group. It's the only main view that can be so filtered. I really wish all the main views could be so filtered. The group sidebar helps, but it's nowhere as good as filtering by group in the main view would be.