RE: Eliminating "changed in Emacs outside of Customize"

["Drew Adams" <drew.adams@oracle.com>]

        The "Changed outside customize" has been a great help for
        me to catch
        those hooks, setq's and poorly written major modes, and I
        think Emacs
        has improved because of it, by fixing the modes and rethinking the
        hooks.

As I mentioned previously, these can still be caught if "changed-outside" is
conflated with "set", and in fact it is more likely that they will be
caught, because users will find them and report them:

       WRT the value of such a distinction in helping us identify
       "hooks, setq's and poorly written major modes" that don't
       play by the rules: I've found (by experiment) that removing
       the distinction changed-outside/set actually makes
       such faulty library codings _more visible_, not less.
       If every change is considered to "set" the option, then
       querying with customize-customize picks up all such faulty
       changes (along with any user changes made inside customize).

       Yes, the same info is available today via customize-rogue. My
       point is that erasing the distinction (in the UI, for users)
       doesn't hamper our ability to find such rogue library coding.
       And in fact it can make it more visible to more users. That
       visibility could help us by inviting more bug reports on
       faulty coding in libraries that we might not check otherwise.

    We could provide an option to continue making the distinction,
    for the sake of testing.

Yes, if there is any value in maintaining such a distinction _internally_,
that could still be done - for testing or in general.

The question is about the _UI_ only. Does it help users or get in their way
to have such a distinction in the UI? I argue that it is clearer for users
without such a distinction.