RE: Changed outside --> set, in Customize UI

[Drew Adams]

    > One problem mentioned is that trying to save a "changed-outside"
    > option might not "work": some library you load might change the saved
    > value to something different after you restart. Well, _setting_ an
    > option in Customize and then saving it might not work either - for
    > exactly the same reason. If users think they can rely on _not_ seeing
    > a changed-outside "warning", then they are misled. If you see a
    > changed-outside warning, beware; if you don't see such a warning,
    > beware. This is a distinction without a distinction.

    Nice theory, but in practice there is a big difference, because in most
    cases the "changes outside customize" either always take place
    or never take
    place, so it's a rare occurrence when the problem you mention shows up.

If, today, most "changes outside customize" occur systematically, that is
because most represent _bugs_: libraries that are diddling user options when
they shouldn't.

In the future, I expect that most such outside changes will be made by users
using other ways than Customize (extensions of Customize, essentially) to
change values. Users will set options in various ways and they will see that
"Set" status correctly reflected in Customize.

Changes to user options should be _user_ changes, and, as such they will not
be systematic, no matter how they are made. When a user wants to make a
change systematic, Save (or Standard) is used.

    And even if it does show up, taking a look at the customize
    buffer when you see the problem will tell you "changed
    outside customize" warning you of the problem.
    What is the problem you are trying to solve, really? I.e. in
    what way is the message "changed outside customize" a problem?

Come on, you can't have it both ways. Either "changed outside customize" is
valuable because it is effective in warning users about disastrous problems,
or it is harmless (might not help but doesn't hurt), has no effect, and
means nothing. Which do you want to claim?

I maintain that it is 1) confusing, 2) ineffective in preventing or dealing
with the problems mentioned, and 3) a meaningless distinction from Set. A
meaningless distinction is not harmless, because it confuses users. Occam
says, "Get rid of it."

Setting an option is setting an option, no matter how or where it is done.
And users should be the ones setting user options, so, yes, the bugs need to
be fixed.

Again - so far, I have seen no argument

    as to why the UI distinction should be kept. So far, all of the
    arguments have involved reference to existing problems that are
    independent of the proposed UI change.

IOW, turn your question around: In what way is using Set instead of Changed
Outside Customize a problem? How about an argument justifying the
distinction, to stave off Occam and his nasty razor?