Search text matches empty string: bug (?)

[Bernard Leak]

Stefan Monnier didn't like a previous message of mine, and
pleaded:

>So, Bernard, could you shows us succinct (but precise) bugs ?
>And please separate unrelated ones into separate messages.

Well, thanks for not *quite* throwing the message away!
Here it is, with less circumstance - and some companion
messages.  Emacs LISP syntax has been used for regexps.

This is seen in GNU Emacs 21.3.1 - I haven't checked
whether it is new with that version.  I don't like the
(apparently undocumented) behaviour when an
empty match is found for a search string in
(query-replace)  - where the search string itself must
be empty - and (query-replace-regexp) .

Either function usually seems to move point forward after
an empty string has been matched - i.e., point ends
up one character after the string matched (or its
replacement, if replaced).  At end-of-buffer, however,
no match at all will be found.

This is quite different from the case in which a non-empty
string is matched: here nothing need follow the match, and
point remains immediately after the match (or its replacement).

Yet a third class of behaviour belongs to regexps which
force matching at a particular point, like "\\`" and "\\=" and
"\\'",
These don't "move on" after matching, and apparently
only ever match once, but they also insist on having
*some* character after point.

I can see the point in avoiding runaway replacements,
but this way of dealing with the problem seems random.
Refusing to match an empty string even once at end-of-
buffer seems especially counter-intuitive to me.  I
haven't found a reference to this in the documentation
(perhaps I wasn't looking hard enough).

                                                                                
Bernard Leak.