Hi Sean,

> I don't believe it's out of the question to wrap macro-parameters in some
> sort of \bool_validate:n (if such a thing doesn't already exist) that would
> run the checks and issue appropriate errors on a case-by-case basis. I
> believe it's important to assume the programmer knows what he or she is
> doing and let them account for this themselves. Otherwise, you introduce
> complexity where none is needed for a large portion of folks.

Can you clarify what your suggested \bool_validate:n is meant to do?
Your description is too short for me to have any idea what it is.

If we leave things as they are, I am pretty certain that programmers
will fall into the pitfall of thinking that

    \bool_if:nTF
      {
        \token_if_eq_meaning_p:NN #1 ? ||
        \token_if_eq_meaning_p:NN #1 !
      }

is safe, even though it will break horribly if `#1` is `(` or `)`
(technically I haven't tested so perhaps this works by chance).

The reason I am certain of this is that I fell into this trap (before
I stopped using boolean expressions), even though I was aware of it.
This is why we need to change something.  The cheapest change in terms
of amount of code and of maintainability is to drop lazy evaluation of
boolean expressions.  This will require changing in minor ways a few
packages where lazy evaluation of boolean expressions is assumed.

> Not to mention that it is just that much more to test and maintain.

Actually, there is currently a mess of code that is only there to
support lazy evaluation.  If we get rid of lazy evaluation, I strongly
expect the code underlying boolean expressions to become simpler.

In fact, I believe it would be possible to provide a form of lazy
evaluation when explicitly requested by the programmer.  Something
like

    \bool_if:nTF
      {
        \tl_if_exist_p:N #1 &&
        \bool_lazy:n { \tl_if_empty_p:N #1 }
      }

would do some trickery under the hood to prevent expansion of
`\tl_if_empty_p:N #1` if `\tl_if_exist_p:N #1` gives the result
`false`.


Regards,

Bruno