Benefits

• Compatibility with GitHub-Flavored Markdown and other Markdown libraries that support this de facto standard (and possibly its variants). This enables copy-pasting from gists or Markdown files within repositories, which can be useful on programming-related sites like Stack Overflow.
• The triple backtick syntax is easier and faster to type than indenting each line of code with four spaces.
• Saves some storage in the database, too! ;)

All the above benefits apply to the new syntax, even without the additional functionality to specify the programming language. With that functionality, I’ll add another (huge) benefit:

• As it’s much easier to specify the language of code blocks using this syntax (compared to the current syntax), I wouldn’t be surprised if this change caused more people to explicitly declare the programming language, so that the syntax highlighting can be more accurate. This is useful for answers that include, e.g. separate HTML and CSS code blocks.

Drawbacks

I honestly can’t think of any. It’s very likely no one is using the triple backtick-syntax at the moment as it doesn’t work; so I doubt it will break anything. If you don’t like the new syntax, feel free to stick to the old one.

Experiences

Ever since GitHub enabled this syntax, I’ve grown accustomed to it. I ♥ triple backtick syntax, and every time I’m forced to go back to the four-space-indent syntax, it feels awkward.

I don't really care either way whether this gets implemented: it's a superfluous extension to Markdown (unlike, say, inline HTML, spoiler markdown, or the as-yet-unimplemented-on-Stack-Exchange table syntax), but it is true the fenced code block has been added to pretty much every Markdown library that doesn't stick to just the original spec.

However, the triple backtick syntax is a GitHub extension, and it's not exactly the "de facto standard" Mathias Bynens portrays it as.

Fenced code blocks, as far as I understand it, were first introduced in the PHP Markdown Extra library as the following:

Fenced code blocks are like Markdown’s regular code blocks, except that they’re not indented and instead rely on a start and end fence lines to delimit the code block. The code block start with a line containing three or more tilde ~ characters, and ends with the first line with the same number of tilde ~. For instance:

This is a paragraph introducing:

~~~~~~~~~~~~~~~~~~~~~
a one-line code block
~~~~~~~~~~~~~~~~~~~~~

Other implementations followed suit, by either supporting only 3+ tildes or supporting both 3+ tildes and 3+ backticks. I ran through the implementations I know of, and Wikipedia's (incomplete) list of implementations (before GitHub went down), and found:

Supports only the 3+ tilde syntax:

• PHP Markdown Extra
• Python Markdown
• Discount
• Pegdown

Supports only the triple backtick syntax:

• ByWord
• Elements
• PEG Markdown Highlight (and derivative Qarkdown)
• R Markdown (only documents triple backtick, but based on Sundown, which supports both)
• markdown-clj
• Showdown

Supports both:

• The CommonMark specification
• Marked App
• Sundown (and derivative Redcarpet)
• GitHub (only documents the triple backtick, but parses both just fine)
• Blackfriday
• Doxygen
• Pandoc
• Parsedown
• Markdown-it

Supports neither, or is unspecified:

• mm2pdf
• peg-markdown and peg-multimarkdown
• MarkdownSharp
• libupskirt
• MarkdownJ
• MarkdownPapers
• Txtmark
• Pagedown
• Dillinger (treats triple backtick code blocks as inline code)

Based on this, I think Stack Exchange should support the tilde syntax, the triple backtick syntax, and the 3+ backtick syntax. Bonus: support of either the tilde syntax or the 3+ backtick syntax should solve the deadkey problem.

The syntax toolbar should continue to indent code with 4 spaces as per the original Markdown spec, or if that's not feasible, it should use the tilde syntax, which has the benefits of being the original version, compatible with GitHub, and marginally more supported by existing implementations.

On Stack Overflow, all the time I'm seeing this happen to people who don't know the syntax.

class Foo {

public static void main(String[] args) {
    // y my code no is working
    Sytem.out.println(qrew3r);
}

}

Some people stop there and never fix it because it's close enough. Others figure out that the first and last lines aren't part of the code block because they're not indented. So they indent those two lines - only those two lines - because the editor doesn't provide an apparent way to indent the whole block.

class Foo {

public static void main(String[] args) {
    // y my code no is working
    Sytem.out.println(qrew3r);
}
}

The result is that we have a site that systematically causes newbs to post questions with poorly-formatted code. Whether or not you like fenced code blocks, when you look at all of the mistakes that users are making, you've got to appreciate that the current UX is broken.

Another reason to include this syntax: Some people are already using it.

However, it makes their posts look kind of strange, since it becomes inline code spread over multiple lines:

This is what it looks like when you put triple backticks above and below multiple lines of text.

By contrast, this is 
a multi-line code block
created by indenting text four spaces.

You can currently specify a language to be syntax-highlighted.

Example:

<!-- language: lang-js -->

    //JS code...

This should not discourage the question, it is even a plus because they don't need to code this feature anymore.

The only thing left to do is to implement the ```` code blocks system (which I believe, is not that hard)

Another major benefit is when marking down code within lists. Creating block codes within list is often a major annoyance, contrast:

- Bullet 1

 Lorem Ipsum (paragraph 1).

 Lorem Ipsum (paragraph 2).

        var foo1 = bar1;
        var foo2 = bar2;
        var foo3 = bar3;

 Lorem Ipsum (paragraph 3).

to:

- Bullet 1

 Lorem Ipsum (paragraph 1).

 Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

 Lorem Ipsum (paragraph 3).

Bulk of the annoyance comes from the editor not being able to do 8-space indents as CtrlK un-indents instead of converting four spaces to eight. "Also, is that blank gap 7 spaces or 9 spaces?"

Of course, the problem is magnified when trying to put block codes within nested lists. Contrast:

- Bullet 1
 - Bullet 1.1

     Lorem Ipsum (paragraph 1).

     Lorem Ipsum (paragraph 2).

            var foo1 = bar1;
            var foo2 = bar2;
            var foo3 = bar3;

     Lorem Ipsum (paragraph 3).

to:

- Bullet 1
  - Bullet 1.1

   Lorem Ipsum (paragraph 1).

   Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

   Lorem Ipsum (paragraph 3).

It gets worse with double nested lists. Contrast:

- Bullet 1
 - Bullet 1.1
     - Bullet 1.1.1

         Lorem Ipsum (paragraph 1).

         Lorem Ipsum (paragraph 2).

                var foo1 = bar1;
                var foo2 = bar2;
                var foo3 = bar3;

         Lorem Ipsum (paragraph 3).

to:

- Bullet 1
  - Bullet 1.1
   - Bullet 1.1.1

     Lorem Ipsum (paragraph 1).

     Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

     Lorem Ipsum (paragraph 3).

Hopefully inserting block codes within list will be less time-consuming after the update.

Another (very) minor benefit is that you can use this syntax to break up code blocks. For example, this code (rendered in an engine) will create three separate blocks with very tight breaks:

```
block1
```
```
block2
```
```
block3
```

I'm not aware of any way to do this using the indent style as unindented lines (no matter how many you interject) don't break the boxes up:

block1





block2


block3

Only drawback I could see is being unclear as to which is the 'right way'. But on a whole I think this would be a great feature to add for someone like me who doesn't want to be using either the button above or spacing in.

The main benefit I see coming from this is that you'll be able to see a little more of the code in the edit box without wrapping. Making it a little easier to specify language is nice too, but I find that the tags take care of it in a large majority of cases.

I'm certainly not opposed, but I don't think it will make fixing code formatting that much easier. You can already select the lines and hit the Code Sample button to add the first level of indent. From there on it's the same amount of work to add additional indents--either copy four spaces and use CTRL-V as a tab key for each line, or copy into editor, fix, and copy back. I think being able to select multiple lines and indent/unindent multiple times would be a lot more helpful than this.

On the downside, ``` would be one of the least intuitive bits of markdown. Doesn't really have the same WYSIWYG feel, at least for me. Using the same sequence to start and end the formatted section could also be a bit confusing, particularly when there are multiple code blocks in a post.

Something like {{{ to start and }}} to end would be clearer, or a custom html tag like, <codeblock></codeblock>, or just allow the <code> tag to span multiple lines to create a block. Or, combine with specifying the language, for example: <java></java>.