Since plist deletion instructions traditionally include either logging out/in or restarting with the expectation that a new, default plist will have been created, won't cfprefsd's loading said new, default plist at login achieve the precise results that were envisioned when the original plist was deleted?
Still not reliable. If at the time you log out
cfprefsd believes that it is holding updated information that has not yet been written to disk, it will re-write the .plist file at that time, creating it if necessary. The end result is exactly as if you had not deleted the file.
There was always a window of vulnerability for this to happen, so it was never guaranteed that deleting the .plist file would change anything. What's new is that the window is considerably larger than it used to be.
The only certain way to get an application's preferences deleted (that is, set back to factory defaults) is to tell
cfprefsd to do it. The only way for a user to talk to
cfprefsd is through the
defaults command at the command line.
This is not a matter of having more than one way to do something, and choosing one method over another based on the situation or personal preferences. This is a matter of having one right way to do it, and one wrong way that may accidentally work some of the time. The "sometimes works" aspect may delude you into thinking it always works.
Notice also that resetting the preferences via
defaults/
cfprefsd happens immediately. There is no need to log out and back in, making this a much lighter-weight solution. (You do still have to quit/relaunch the app, because the app
may have cached the answer it got from
cfprefsd, and you need to force it to ask again.)
