The attached patches of `simple.el' and `compile.el' add and respect a new
value, `until-move', for options `next-error-highlight' and
`next-error-highlight-no-select'.

The value of `t' is not adequate in a one-buffer-per-frame environment (mine, at
least). The problem is that the overlay gets deleted upon the next command, and
a switch-frame event can act as the next command. Much of the time, the
highlighting is never seen, because a switch-frame event (whether from the user
or the code) causes it to disappear too quickly.

Regardless of whether you are convinced that that is a problem, I would argue
that a user should be given the option of showing the highlighting until the
locus changes, regardless of the next command.

The new value `until-move' does that: it moves the overlay when you change
locus, but it does not delete the overlay upon the next command. IOW, it does
not put `compilation-goto-locus-delete-o' on `pre-command-hook'.

(Personally, I'd prefer that `until-move' be the default value, because I think
it makes more sense for others too...)

You may argue that if the value is `until-move', the overlay is never deleted.
Correct. So what? A user should still have this option.

In practice, it doesn't bother me at all that the overlay remains, and I've been
using this for years (long before Emacs itself had such highlighting). 

If you really want a way for the user to get rid of the overlay, then let `C-u
C-u C-x `' do that, by adding this to the beginning of the definition of
`next-error':

(if (and (consp arg) (= 16 (prefix-numeric-value arg)) 
         compilation-highlight-overlay)
    (delete-overlay compilation-highlight-overlay)
  ...)