Happy for the thoughtful feedback.

Perhaps, some expanded advice in the docstring for setopt?

"Set VARIABLE/VALUE pairs with enforced types, and return the final VALUE.

This is like setq, but is meant for user options instead of
plain variables.  This means that setopt will execute any
custom-set form associated with VARIABLE, and strictly ensure
that VALUE is of the type declared by the user option.

Example: If the user option is declared to accept a `float',
set the option to 2.0, not to 2 which is considered an `integer'.

Note: Many user options accept more complex types than a scalar
float and that may pose a challenge to address when setting them
in elisp using setopt.

If you encounter a discrepancy that cannot be addressed by amending
the type specified by a setopt call, and you can deem the desired
type compatible nonetheless, use setq. If the user option has an
associated \"setter\" you may invoke it manually using ???"

Then there's the twist that some options force content checks, not just
type checks. An example of a user option that is intended to be overridden
with custom entries is tab-bar-format. The setopt type checker will barf on
entries not strictly in the tab-bar-format pre-populated list despite the
type being a normal hook.


On Wed, Sep 11, 2024 at 6:53 PM Stefan Kangas <stefankangas@gmail.com>
wrote:

> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
> > I tend to agree.  If the type doesn't accept the value, you can use
> > something lower-level than `setopt`, while you argue with the maintainer
> > to try and get them to change their type.
> >
> > IMO, the whole point of `setopt` is to check the value against the type.
>
> +1
>