Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.
Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.
The idea of a centralized grammatically-accessible configuration store was a good idea (albeit this isn't want the registry was "for" originally-- it was just a file-type registry originally). GConf was a similar idea.
Devs misusing the registry to store opaque binary values (especially gigantic ones), accessing it with too high a velocity, and having a less-than-stellar file format have hurt it, for sure. Having few good schema rules or APIs that limited arbitrary developer access didn't help either.
Then, we should talk about, when they are in conflict, which one comes first.
Having said, that level of technical skill req'd to edit an INI or the registry is about the same. Either way you're talking about a non-technical user descending thru a hierarchy of strange-to-them named containers to get to an arcane-looking location where settings are saved.
The user is going to call me when they have problems. It's easier for everybody if I can just administer the software centrally so they don't have problems to begin with.