In this particular example, it would be best to apply code style to the sample code part of the comment, using double back-ticks, as hinted by the comment form:
I can report that this bug still exists as of 8.6 (I was about to file a bug report but did a search and found this one). When I used the web_api to add a comment and then fetch it, I noticed that the equals sign had been turned into < h 1 > (but with no spaces, i.e., an HTML header tag) which probably explains the appearance (everything after the missing equals sign being rendered in a larger font, since the web browser interprets it as HTML). (The comment that comes out of the web_api call also has the closing tag added. I guess they figured if they’re going to mangle comments, at least mangle them consistently… )
(To add a clarification: I got the equals-to-H1-tag conversion using the web_api rather than the web portal, so the conversion seen by the OP is not being done by the web browser itself, but something common to both the web portal and web_api.)
So is there a workaround for this? I tried changing the = to an HTML entity, but neither Xequals; nor X#61; (replace X with ampersand in both) work. It appears that in THIS case, it decided to turn the ampersand into the HTML code for ampersand.
So it seems I can’t win – it mangles non-HTML into HTML and vice versa.