Steps to replicate the issue (include links if applicable):

• Open a page in wiki text editor and add a comment.
• Make a comment like <!--&gt; &lt;!-- --!&gt; --&gt; --> or <!---&gt; &lt;!-- &apos; --&#62; --&gt; --!&gt; &lt;!--->
• Switch to visual editing.

What happens?:
The "invisible comment" textbox displays the comment text as &gt; &lt;!-- --!&gt; --> and -&gt; &lt;!-- &apos; --&#62; --> --!&gt; &lt;!- respectively. VisualEditor only recognizes the string --&gt; as an escaped end of comment. It does not recognize the identical --&#62; or any other HTML entity that appears even if said entities are used to escape strings that can't appear in comments per the HTML5 spec like --!> or -> at the beginning of a comment. This presumably happens because --> needed to be escaped in Visual Mode comments and it was special cased. On a brief sidenote that feature at least seems robust. The string --&gt; is correctly escaped to --&amp;gt; although, again, when going the other way from source to visual &#38; as part of --&#38;gt; is not unescaped.
What should have happened instead?:
At minimum VisualEditor should recognize --&#62; as an end-of-comment and &#38; as an ampersand for consistency. The ideal solution in my opinion would be to unescape everything but that might not be preferred since editors expect text in comments not to get parsed. A compromise then would be to recognize escaped sequences if those aren't allowed to appear in comments. These are, --!>, <!-- and -->(already behaves correctly). In addition, the strings > and -> at the beginning of a comment and <!- at the end. (Note that VisualEditor adds space around comments so these don't come up in Visual Mode.) For the example comments this means unescaping everything except the apos. In addition, ampersands will need to be escaped if strings like --!&gt; and --!&#62; appear literally in a comment created in Visual Mode.
Software version (skip for WMF-hosted wikis like Wikipedia):
I found this on the English Wikipedia

Other information (browser name/version, screenshots, etc.):
This doesn't sound like it should be affected by browser but I tested it on Firefox.

A testcase