Frankly, I wasn't even aware of those existing command line arguments ...
But if we could get that working, it could literally save us hours of troubleshooting each month, so that would be really worthwhile - especially because there's really only half a dozen of folks here who regularly help provide support to new users, and because you obviously need to be fairly familiar with FG internals to troubleshoot in the first place. So excluding autosave/fgfsrc stuff would be a great time-saver, maybe even with an option to override these files by using either custom files via --use-fgfsrc=foo.fgfsrc, or a PropertyList-encoded file with embedded fgfsrc/autosave sections for troubleshooting purposes ?
This may seem a little tangential at the moment, but being able to save/load and override startup profiles without having to teach new users how to locate $FG_HOME would free quite some forum resources
Ideally, the log file would explicitly state that these options are in-use, right at the top of the file, maybe even dumping fgfsrc/autosave.xml into the property tree for runtime debugging - but also for replicating all relevant stuff in the log file
EDIT: Okay, looking at the code in fg_init.cxx, I think it would also be better to load another preferences.xml from $FG_HOME (and provide an option to override/ignore that), simply because we could then make $FG_ROOT/preferences.xml readonly during installation and generally discourage people from editing the "global/shared" preferences.xml in $FG_ROOT and instead only ever edit their own preferences.xml in $FG_HOME - which should align well with modern multi-user operating systems, and which would also mean that users no longer need to modify the global file, and can't affect other users.