As you point out, using the application file name as the index into the database can cause some unwanted settings when you have two different programs with the same file name that require different settings.
That may be a type of overengineering. I guess you can write a rather simple database app which has recorded settings in the usual WPS setup string format, and - if you really want that - which queries settings of existing objectsand repairs broken ones.
Presumably a real new setting, a WPS setup string with "SET FOO=BAR" was already supported but not visible, comes with an own new setup string. E.g. "SCHEDULED=20121231235959".
My database is Rexx-shaped, because e.g. inserting a "SET FOO=BAR" or "ICONFILE=..." is easier that having to create and/or use some DATABASE.TXT format with exactly the same setting. I do still use DATABASE.TXT for a few Win-OS/2 apps, like MS Office's (not really motivated to find out differences compared to defaults and DATABASE.TXT).
I wouldn't mind having a customized/personalized or improved/modernized DATABASE.TXT, but an own Rexx script which contains both the data (SET FOO=BAR) and the data processing (a.o. SysCreateObject) is more efficient.
I could create records, like a customized record #1 with SET FOO=BAR and ICONFILE=... in a text field.
FWIW, ivan may be listening: the Rexx code is easy if you know the environment. Typically just lines with SysCreateObject, SysCreateShadow, SsSetObjectData or SysIni. Almost a configuration file instead of a computer program.