The CommentStoreComment class, encapsulating a comment (edit summary, log message, etc.), was added as part of the big comment refactoring in T166732. It can contain not only a plain string text, but also a Message and additional JSON data. If a Message is present, the text is supposed to reflect that message in the content language, but the Message may be used to render the comment in the user language instead. Wikibase currently achieves a similar result via the FormatAutocomments hook, but CommentStoreComment has the potential to be a nicer and more general solution.
However, the class is currently not used to its full potential. CommentStore is responsible for saving and loading CommentStoreComments, but most of the places that use it to load a comment discard the comment object pretty soon and only use its text, equivalent to the old comment field prior to the comment refactoring. We should change this, use CommentStoreComment objects as much as possible, and render them properly, including translation via the message if possible.
How exactly this proper rendering looks like, though, is not yet clear. The most conservative approach, and what I think seems to have been intended during the design of the new comment system, is to take the ->text() format of the message and format it just like a regular comment (i. e. Linker::formatComment: sanitize, format /*autocomments*/, format [[links]]). However, this system is fairly limited in the formatting of the message, and it also means that any comment syntax in the message will be formatted, whether that was intended or not (e. g. plaintext params of the message would not really be plain text). In other words, while the message may contain structured information about the comment, this approach would not make use of it. To me, this would be passing up an opportunity to solve bugs like T186035 and T215929. (It is possible to fix those bugs in other ways – @Anomie suggested using invisible characters, like U+200B, to escape parts of the message – but that would have to happen before constructing the message.)
Another approach is to ->parse() the message, if it exists, and bypass the usual comment formatting. This gives the creators of the CommentStoreComments, e. g. Wikibase, much greater flexibility: they can use full Wikitext parsing in the summary, and parameters would be correctly escaped according to their type (e. g. plaintext params would stay plain text). However, this is not fully compatible with the original comment model: that the comment text corresponds to the ->text() of the comment message in the content language. Instead, the comment text here would contain arbitrary Wikitext, and anyone who uses the comment text instead of the CommentStoreComment proper would just see the Wikitext. Within MediaWiki, this would mean we should migrate to CommentStoreComment fairly quickly; but users of the comment.comment_text field on the replica databases, or of the comment revision prop in the API (as opposed to parsedcomment, which would now actually ->parse() the comment), would still be affected.
@daniel had an idea to mitigate this problem, though: creators of CommentStoreComments, e. g. Wikibase, could override the ->text field of the CommentStoreComment to be a more suitable textual form of the message, instead of the ->text() of the message, before passing it to CommentStore (or PageUpdater::saveRevision(), etc.). In the trivial case, this could just be “textual comment not supported”, but they could also format a simpler version of the message, or check if arguments need to be escaped with U+200B or similar.