Pandoc already supports % at the start of each line for comment syntax, and as @benhourigan pointed out, it’s more Markdownish than HTML comments. I don’t think we need to have so many different ways to add comments, such as partially commented lines and fenced blocks. To keep things simple we can use the same rules as block quotes. Instead of > for starting a block quote, use % to start a comment. Require the symbol at the start of each paragraph that is to become a comment. This, together with line blocks for pre-formatted text, would compliment the existing block quote syntax and feel like part of the same language, rather than adding a fenced block syntax for comments which would not feel like part of the same language.
It’s also not a problem commenting out whole sections without a fenced block syntax, assuming the writer has a good editor. Ctrl+/ for commenting/uncommenting a block works in a number of popular code editors such as Atom and Visual Studio Code; this shortcut could be added to popular Markdown editors as well.
There has been some talk of using Jekyll-style blocks for metadata, variations of which are used in both Pandoc and MultiMarkdown. If we do go down this route, this block could be used as the basis for comment block syntax too. They are the same semantic family: extra information that is not rendered in the HTML output, so there’s less cognitive overhead for people learning the syntax (technical users or otherwise). But it would be simpler to have just one metadata syntax, so perhaps % at the start of every line could be used for other metadata too, and not have a block syntax for metadata. e.g. to include metadata about the document, just include these comments before everything else:
% Title: A Sample MultiMarkdown Document
% Author: Fletcher T. Penney
% Date: February 9, 2011
% Comment: This is a comment intended to demonstrate
metadata that spans multiple lines, yet
is treated as a single value.
% CSS: http://example.com/standard.css
I’ve also recategorised this topic under Extensions and added it to the list of proposed extensions, since the core CommonMark spec focuses on features found in the original Markdown spec.