It is more or less 100% impossible to "detect" a "known working
server config".  The X server can very easily start up and have
no crash whatsoever, load the video driver, have no crash
whatsoever, and end up with a display that is totally corrupted
due to a buggy driver misprogramming the accelerator chip, with
absolutely no way of being able to detect that other than a human
eye seeing it and saying "Um, that's not right".  Or mode timings
being calculated or programmed slightly wrong and resulting in
wavy lines or a shaky image on the display, all not "visible" to
the computer in terms of being able to read a register.

In other words there is no RADEON_SCREEN_IS_SHAKY register you can
read to tell if the screen is shaky or not.  There is no way
of detecting many problems that commonly happen, which are caused
by a variety of different things including:

- buggy video driver
- buggy video BIOS
- buggy kernel
- buggy hardware
- overheating
- bad video memory
- incompatibility between hardware

or any number of other problems.  If the X server were to assume "I didn't
crash, and made it to this point in the code now, so everything seems ok,
I'll just call SaveBackupConfig() to store this config because it seems
ok - the server doesn't have any way of knowing if this is visually the
case to the user.  The result would be the X server saving a *broken*
config file as the "safe backup".

So while your idea definitely has merit, the suggested solution is
impossible to implement in reality due to the nature of the problems
that can cause the server to not start up correctly, or to start up
and be unable to tell if things are correct.

Instead of looking at the trees though, if we take 10 steps back and
look at the forest, we change the problem->solution from being:

Problem: X server doesn't save a backup config that it knows works.
Solution: Make the X server save a backup config that it knows works
          because it started up ok

We change that into the _real_ problem:

Problem: The X server requires configuration in many cases where it
         really shouldn't need configuration in order to start up.
Solution: Improve the X server, it's drivers, to autodetect as much
          aspects of the hardware that it can, and to start up with
          a simple built in configuration that is as highly likely
          as possible to work properly.  Something like Windows safe
          mode.  Then, an X client (or set of clients) started up
          from the server startup scripts, communicate with the
          server at runtime, to make it switch to the native video
          driver, change resolution, rotate the screen, change color
          depth, enable/disable 3D, configure your special 25 button
          mouse with 3 scroll wheels, etc.

As crazy as this sounds, people are slowly moving the X server into
doing that.  Making it more hotpluggable, and making it plug and play
friendly to borrow a term from the 90's.  In the future, once such
features get completely implemented, then everything will be much
more simple to begin with, and people wont even know there is a
config file.  Hopefully there wont even be one for the server.

To take this request 100% literally though, rather than looking at
the bigger underlying problem as I've just attempted to present it,
it's just not feasible.  The closest you could approach it, is something
like Windows does, where you change a setting and it displays a dialog
box for 15 seconds that says "I'm going to show you this for 15 seconds,
and if you can read it and everything looks ok, click YES, otherwise
click NO or wait for the timer to run out and I'll revert the setting."

Only, even if things look/work ok for those 15 seconds, it could lock
up relentlessly 3 minutes later due to a driver bug.

And anyone attempting to implement a solution like I just described,
would be doing it outside of the X server, as a separate application.
The server doesn't need modification for this at all really.  You have
an app that tells the server to change setting foo, it remembers what
the setting was before that, changes to foo, puts up the "does this
work" dialog, reverts the setting if you don't say yes, or keeps it
if you do say yes.  When it keeps it, it writes out the new config
option.  For existing servers, that would be xorg.conf, for the
future, there hopefully wont be an xorg.conf, but instead a server
that is configured entirely at runtime via an X extension of some
kind.

Sorry for the lengthy comment, but I thought it was worth stating this
here, in hopes it helps others to understand the impossibility of the
request, at least as originally requested.