Since you have ignored every single one of my suggestions despite the fact that I am the second-most senior authority on the subject I can only assume that you aren't willing to listen. Never-the-less, like any good "father" I'll repeat my lecture hoping the kiddies will catch on.

All of the rationalizations that you posted are wrong. I don't mean that the ideas are bad, it's just that :
For all games (except for some games made after 1991 and few random exceptions based upon the mame devs mood when they made the entry) the Term "US" is not in the game name. That means that your filter simply won't work for at least 50% of the games in mame. Heck even the example we have been using, Pac-Man, doesn't have a rom revision with a "US" in the title and the parent is the japaneese puckman.
Can you get close? Sure. But so can built in filters in front-ends that you can manually tweak for the games it doesn't work on, so what exactly is the point?
Outputting to plain text is good... but if you use any database engine to generate then dlls have to be installed on the users computer to run the program, which leads to various compatability problems. (find me a database engine that works well, and installs well and easily on all versions of linux, windows and dos and I'll take it back) Again, k.i.s.s. You can easily filter using straight code.
How do multiple gamelists have anything to do with filtering? If the front end is properly coded then you should easily be able to make a single gamelist with the clones filtered off, the front end should be able to turnicate names with a simple setting, and you should be able to make exceptions for special cases. (like manually removing puckman and adding pacman in it's place). If your front end of choice can't do that, then may I suggest you start using a better one.

Why am I making a federal case out of this? Simple.... just because you don't play the japaneese clones 99% of the time doesn't mean that you don't need the option to occasionally manually add a few. An example is marvel vs capcom. (if it's the wrong sequel don't kill me fanboys) In the japaneese version there is a special character not available in the Us or world versions. Also sometimes the Us version doesn't work while the other regions do. And on these rare occasions in which you want both parents and clones to be visible, you'll need the data in those parantheese that you filter off the game name so you can tell them apart.
Remember.... if you want to make a public utility that is actually useful, you can't base the type of filtering it does on what you find useful, else it'll only be helpful to yourself and maybe two other people. So again, I repeat.. filtering at the masterlist level is a bad idea.
I think your idea has merit.... it's just the direction your going towards is the wrong one.
Making a program that pre-filters lists one way is a bad idea. If you need it personally then great, but it's not a particularly useful utility to the masses. I've made plenty of these little program-ettes, I just don't announce them on the software board as a utility and they are quietly added to my website.

Making a more generic program that filters lists any way, depending upon the variables the user gives is a great idea. You could even add quick templates to filter the lists in the way you suggested. I see nothing wrong with that. Front ends could be designed to call it via the command line and then fe developers could completely ignore list generation and leave it up to you.
Tampering with the data is still a big no-no though, especially if the front-end "broadcasts" the data to a companion app. Garbage in, garbage out. The real key is getting the front end to display it the way you wish, not to fudge the data itself.
A good example of this are these people who write batch programs to rename all of their console roms to something other than the goodtools naming conventions. Way to go, now you have to manually rename all of your console artwork and when you download new artwork you have to mess with it yet again. The real solution is the front-end developer allowing the user to hide part of the filename when it's displayed in a gamelist.
I'm sure your response will be along the lines of "some front ends don't support these features you mentioned". Yes that's very true; you shouldn't use those front ends then. I mean there are plenty of advanced windows front ends and I believe that Kymaera works on linux and dos now, and since both options are generally skinnable (meaning you can still make it look like another fe if you really want to) I can't see any real point in using a simplier fe, unless you want a really simple setup, in which case you probably aren't concerned with any filtering what-so-ever.
I'm just trying to put some logic behind your intentions. It's my understanding that you are trying to make a nice turn key solution to filter the games in the way you mentioned for users that don't want to muck around with complex filters and gamelist generators. The only problem is, as I've shown with my examples, it's quite impossible (or at least impractical) to filter the lists the way you want them filtered automatically, with the "error" percentage low enough to where it's acceptable to most people. So that leaves manual tweaking, which means users have to muck around with complex filters and your gamelist generator. Logic dicates that the specific goals you have set for yourself can't currently be met. Unfortunately the blame lies in lack of data. There isn't reliable, readily available, data for the fields to wish to sort by. It's as simple as that.
I'm sure this will be looked upon as a "flame post". It's not, if I didn't respect what you were trying to do then I would have just said "it sucks" and left.