By that I mean that I think a tweaker should perhaps
be _just_ a tweaker, something that potentially
handles anything that is a single independent setting.
It should be almost totally data driven, with a simple GUI (categories, subcategories, value validation); all
data living in a plist. Also extensible, with plugins
for different mechanisms (defaults, launchctl, etc);
the plugins would deal with temporary vs permanent
(if applicable), and there might be additional
plugins for value validation beyond that common
for value types appearing in plists, and for
applicability verification beyond what would
always be done (OS version) and what would
always be done by a particular plugin.

The data would include basic applicability
description, mechanism, mechanism-specific
elements, GUI placement (category, subcategory),
date added, and some sort of UUID. The data would be
user-extensible through the GUI, and could
optionally be submitted to a central database
of candidate updates, in return for a UUID;
if a submission was accepted and redistributed,
it would retain that original UUID and on update,
replace the user’s original entry (for uniformity);
this would require that the “how” details were
unchanged (GUI placement and descriptive text
might change). Validation of candidate updates
and data maintenance (consolidating entries
for individual OS versions, for example) would
be done by a set of “trusted” volunteers. Candidate
updates, approved updates, new plugin distribution,
all would use distributed infrastructure; all updates
would be signed, and the plist would have
a three-part overall version number (major=
incompatible changes, minor=compatible changes
that may require new plugins or plugin updates,
micro=updates that don’t require major or minor
version changes), as well as a timestamp.

Resource editing might also become a plugin.

By being run in a batch form at system or session
startup, this could optionally make persistent any
tweaks that would otherwise be non-persistent;
an additional message should be present if there
were undue risk of painting oneself into a corner
by doing that.

Security and privileges should be honored; non-admin
users should only be able to change their own settings, while admin users should where applicable
have a choice of scope.

The only fundamental limitation is that each tweak
should be something that can be adequately validated independently of any others. Even that could perhaps
be circumvented by validation plugins, that would
only allow certain settings to be changed in
reasonable combination; but then all the value
fields would have to be able to fit onto a single
line in a list view in the GUI; the schema could
accomodate that with the use of appropriate
combinations of dictionaries and arrays.

Ideally, once it was bug-free, there would be
no need for changes to the basic program, only
data maintenance and occasional new plugins.
This mechanism would take advantage of
distributed knowlege; as new tweaks were submitted,
the program would grow ever more capable. And
since each record had a timestamp, one would
be advised of new tweaks as they were distributed.

Seems to me that 90% of the work would be getting
the schema right; the rest would follow.

The only problem is that either someone pretty
big would have to do it all (if it were commercial),
or the support would have to be from a large
pool of volunteers (if it were free), because the
support infrastructure really needs to be distributed
for updates to be verified and distributed promptly
and with high availability.

No, I haven’t used XCode enough (i.e. at all) to
whip out something like that reasonably quickly;
and I don’t have the time right now to flesh out the
design, and then either learn XCode or do it
the old-fashioned way (Makefiles and hand-coding).
However, I hereby grant a free license to anything
unique I might have mentioned, for anything
distributed free and open source. Any other rights
are negotiable.

The data acquired by such a tool could also be used
by other tools, that simplified matters by being
“smart” about tuning for certain objectives
(performance, choosing look and feel options that
were as much as possible like some prior version,
etc). Ideally those would also be open as to what
they did, but would not necessarily be free or open
as to their code (even coders have to eat, pizza&beer
isn’t usually free).