It worked for me; I don't have an OS X license, so I can't account for strangenesses on that end. Here is what I get from Fedora and Ubuntu machines:

1: Could not replicate this. Backward search always searches to top of file from any position, then stops. The only way I end up at the end of the file is if I was already at the end and search for something which is at the end. For example, if the end of the file says FROB and I am anywhere above that and type ?FROB - I get the standard "Pattern not found" message.

Maybe some option is causing less to wrap backwards, or a different key is being hit or something like that. Another likely possibility is that the page is changing rapidly AS you enter the initial letters, then staying on where it was last - causing some confusion about the position change. In that case, it would depend on what you were searching and in what file. This is part of why the default less behavior with the 'enter' key to explicitly trigger a change is arguably less confusing.

2: Replicated and fixed in HEAD. I wasn't hearing any bells because I always turn terminal bells off.

Vanilla less always rings the bell if you are already on the last hit and search again. The patch implements the 'incremental' by launching a new search with multi_search() on each keystroke (this was intended to minimize the invasiveness of the patch). So it rings the bell multiple times if you are on the last hit, explaining the weird specificity of 'if the last match is in view'. Fixing this requires either redoing a lot of the plumbing or just adding and using a global. Since the existing program already uses globals liberally or even preferentially, I did the same.

3.1: Replicated - this was the same call to eof_bell() you saw in 2.  It is not occurring for me since the patch to fix #2, in either forward or backward searches

3.2: Not replicated. I don't see anything like this. Maybe it is related to OS X terminal libraries or even the specific terminal app you are using? There are many possible ways to redraw the search string but if I can't replicate it without an OS X license, just changing it blindly is a crap shoot. There are now changes in HEAD which might conceivably help but if not, it would help to have either more detail, or replication on a different environment

3.3: Replicated, good catch. This is for the same reason that hitting / and then enter normally repeats a search in vanilla less. Should be fixed in HEAD.

3.4: Not replicated. If I type /SHELL and then press backspace exactly six (5+1) times, the search is canceled. Every command in less has the same behavior here.

If it happens that the issue is that less should "do what you mean" and cancel the search if you delete the search pattern but not the /, that is doable but it would be broken for anyone who wanted the default less behavior, which leaves the / there and keeps you in search mode. unless you explicitly delete it.

Another possibility is that some of the display issues you were complaining about might have led you to believe that the search was not yet canceled when it actually was (in terms of everything else, like what the program would do with further input).

I would like to suggest that actually there are some other good pagers you may prefer to use. For example, vim can be used as a pager and provides a beautiful incremental search that cancels on ESC and many other details like color syntax highlighting, etc. For example, the only reason I typically use less is that I am being lazy or am on some remote system I don't typically work on, in which case I don't care much about extra features not provided by less -R. If none of these meet your requirements you may find that it is easier to write a pager than to overhaul less... AND somehow get upstream to accept a lot of changes in the service of features which old school users probably don't care about. 

Cheers!