Thank you very much for this quick reply and fix, Alan! Yes, from a 
couple of tests, this fixes the issue I was having (and stops me from 
getting distracted by constantly changing fontification while writing a 
comment – thank you!). I'll let you know if I notice any remaining issues.

This does not fix the issue I'm seeing with fontification of variable 
names in python-mode (which also appears to be an Emacs 28 regression), 
but given that this fix is specific to cc-engine, the python-mode issue 
is apparently different. That one seems a little harder to reproduce, so 
it may take me a while to develop a simple reproducer for it, especially 
since I haven't been doing much python programming recently. However, 
please let me know if you would like me to prioritize opening an issue 
for that one: I can do so sooner if it would be helpful.

Thanks again,
Bill

Alan Mackenzie wrote on 7/29/22 11:44 AM:
> Hello, Bill and Eli.
>
> On Fri, Jul 29, 2022 at 08:56:21 +0300, Eli Zaretskii wrote:
>>> From: Bill Sacks <sacks@ucar.edu>
>>> Date: Thu, 28 Jul 2022 14:32:09 -0600
> First of all (Bill), thanks for taking the trouble to report this bug,
> and thanks even more for cutting the test case down to the short fragment
> in your screenshots.
>
>>> Starting with Emacs 28, I have been seeing font-lock issues when
>>> editing C and C++ code. The situation where I see this the most
>>> (though I'm not sure if it's the only situation) is when I am writing
>>> a comment and currently have a space at the end of the comment line:
>>> in this situation, the fontification of a variable name or function
>>> name on the next line becomes broken until I type a non-space
>>> character to end the current line.
>>> The attached screen shots illustrate the problem: nospaces.png shows
>>> the correct fontification; space_before_var.png and
>>> space_before_function.png show that variable and function names lose
>>> their fontification when there is a space at the end of the previous
>>> comment line. Running M-x font-lock-fontify-buffer temporarily fixes
>>> the issue.
>>> The problem occurs even when using emacs -Q. I have tried the latest
>>> emacs28 pretest and the latest nightly build available from
>>> emacsformacosx (though with my customizations – NOT with emacs -Q)
>>> and those also exhibit the problem. The latest emacs27 from
>>> emacsformacosx does NOT have this issue.
> This is a coding bug in an optimisation from March 2020, where the
> complaint was that scrolling over a 2,000 line macro was slow.  The fix
> neglected the possibility of spaces at the end of comment lines.
>
> Could you please apply the following patch in your Emacs-28.1, byte
> compile the file ..../lisp/progmodes/cc-engine.el, then try out the
> result on your real code.  (If you want any help with the patching or
> byte compiling, feel free to send me private mail.)  Then please confirm
> that the bug is fixed, or tell us how it's not fixed.  Thanks!
>
>
>
> diff -r 9c649274b259 cc-engine.el
> --- a/cc-engine.el	Tue Jul 26 20:08:39 2022 +0000
> +++ b/cc-engine.el	Fri Jul 29 17:25:16 2022 +0000
> @@ -1679,9 +1679,13 @@
>   Return the result of `forward-comment' if it gets called, nil otherwise."
>     `(if (not comment-end-can-be-escaped)
>          (forward-comment -1)
> -     (when (and (< (skip-syntax-backward " >") 0)
> -		(eq (char-after) ?\n))
> -       (forward-char))
> +     (let ((dist (skip-syntax-backward " >")))
> +       (when (and
> +	      (< dist 0)
> +	      (progn
> +		(skip-syntax-forward " " (- (point) dist 1))
> +		(eq (char-after) ?\n)))
> +	 (forward-char)))
>        (cond
>         ((and (eq (char-before) ?\n)
>   	    (eq (char-before (1- (point))) ?\\))
>
>
>
>
>> Alan, this seems to be a regression in Emacs 28, so could you please
>> look into it?
> Eli, Do I understand you want the fix in the release branch?
>