1) I once saved the whole CPG database before moving to a new server and after importing the DB CPG went all crazy and i had to setup everything from scratch, could have been a one-time thing but nevertheless not the optimal solution...
You probably haven't created the dump properly, which is sad for you, but not really a valid reason to create a complicated feature that will create a proprietary backup. In an ideal world, coppermine could create a database dump for backup purposes. That's what the existing backup plugin does. That's what
might go into a future version. What will not go into future versions is your suggested special flavor of XML data that just serves as failure-prone surrogate for a real database dump.
If you have created a dump and want to make sure that it will work as expected, just attempt a restore on a temporary platform (a local testbed would be fine for that purpose, e.g. the Coppermine Live Demo), before deleting the source (or before the source get's inaccessible because you switch webhosts). That's best practise for all kinds of database-driven apps. There really is no reason to change that, as your proposed method would inherit all possible flaws that database dumps have (danger of timeouts for large dumps, problem of escaping special chars properly, collation issues etc.).
While we welcome your suggestions and want to encourage you to keep on contributing in one way or the other, we have to turn down your feature request. Marking thread accordingly. Please don't get discouraged by that: maybe you had a bad start with mySQL dumps, but they really work fine once you understand where the problems lie.