I have been thinking about these two bugs extensively, and it looks to me that 1031876 seems to me like misunderstanding, and either is an issue in the testing documentation, or is a problem of slightly different nature. However, this (1031908) is a valid bug in my opinion.

Having given a closer look at 1031876, one can notice that the *viewer* never crashes due to lack of the config file (daemon on the other hand does so). The viewer will face problems when ~/.cache/accomplishment is emptied while the daemon is running, as it has no trophy icons cache available. The viewer will not have problems because of ~/.config/accomplishments is cleared, as it never accesses it, it's the daemon who takes care about that.

And therefore, I consider _this_ (1031908) bug as a valid problem. 1031876, however, is related to a slightly different issue - the viewer crashes on startup when *icon cache* is missing, not when *config files* are missing. That means your branch [1] does not exactly what is needed to fix this issue, as it makes the viewer ask the daemon to recreate config files if needed. What actually needs to be done is that the viewer should - in such case - ask the daemon to recreate trophy icons cache. Ideally, it should ask it to do so only when it's actually missing, not blindly requesting this on every startup, as this may (when the accomplishments collection grows up) significantly increase the time the viewer needs to start. 
Another thing that bothers me in that branch is the use of DBus signals. Note that the viewer will execute config_files_initialised(...) not only on startup, but every time corresponding signal is set. That means if I run another instance of the viewer, config files will get (pointlessly) initialized, and the first instance will misbehave, as it will partially re-initialize too, as config_files_initialised(...) will be called. [And by the way, it seems to me you have accidentally left dbusapi.init_config_files() commented out].

Now about the daemon - I do agree it should recreate the config files if they are not present. It seems logical that it should happen when the file is needed - so when one of the API's config access function is called. Your other MP [2] does it another way - it prepares the daemon to be able to recreate these files when the viewer starts. As I explained in previous paragraph - it's not needed in such case. This should happen when whoever uses the API functions that access the configuration stored in file (this may not necessarily be the viewer, it may be any other application, and that other application would simply use that API call, without having to remember to run init_config_files() before [and waiting for it to complete!]).
And there is something else I need to complain about your branch - the init_config_files() method is really confusing. It does a lot of different unrelated initialization things, and potentially modifies significant variables. We try to keep our API as clean as possible, and structuring methods by what they actually do is a key part of that - therefore I would prefer if the function that is meant to initialize config files would do just that.

Because of all these reasons, I have to reject both your MPs. I am sorry for that, as I appreciate your work. If you want to fix these problems in an alternative way, feel free to consult me about solution details. Also, if you or anyone else wants to re-open these MPs and discuss them, you are welcome to.

  [1]: https://code.launchpad.net/~notgary/ubuntu-accomplishments-viewer/fix-for-1031908/+merge/118241
  [2]: https://code.launchpad.net/~notgary/ubuntu-accomplishments-daemon/fix-for-1031908/+merge/118242