bug#22043: 25.0.50; search-forward and char folding

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

> > Isn't it correct and sufficient to say that non-regexp
> > incrementalsearch uses character folding by default?
> 
> No, because "C-s RET" actually invokes a regexp search behind the
> user's back when character folding or lax-whitespace are in effect,
> and the user has no way of knowing whether it invoked a regexp or
> non-regexp search.
> 
> > IOW, isn't this default behavior true for all incremental
> > search commands except regexp search, and only for those
> > commands (no non-incremental search commands)?
> 
> No.  Nonincremental vs incremental is not the issue.  The issue is
> whether the search function that the command employs uses regexps or
> not.  It is a limitation of how these features are implemented that
> they absolutely require regexp search.

OK, but from a user point of view, is this not the case:

1. S?he invokes search using `C-M-s' or `C-s', which are
advertised as regexp and plain (non regexp) search.  IOW,
regardless of what might go on under the covers (and a
lot already does, for lax whitespace searching), s?he
thinks of `C-s' as performing a non-regexp search.

2. There is no character folding with the "regexp" commands
(`C-M-s'), because char folding substitutes its own regexp
for the user input, and char folding does not currently
parse regexp-pattern user input.

Perhaps, to be more precise, the difference is search that
does or does not accept general regexp patterns as _input_.
Those that do have "regexp" (or "-re-"?) in their name;
those that do not do not have it.  The former do not
support char folding; the latter do.  Is that correct (and
complete)?

I guess I was mistaken in thinking that non-incremental
search commands, such as `nonincremental-search-forward',
do not support char folding (regardless of whether they
include "-re" in their name).  Which ones support it, and
under what circumstances?