See https://github.com/spf13/hugo/milestone/14
It is room for some more, I guess.
And I have put both of the issues below in there, but I think I will only pick one of them for this version …
I see big value in both of them, both seem equally fun to implement, so which one should I pick…?
Both issues are interesting, but I’d vote for Custom Output types, which I think would have broad appeal, based on my own needs, discussions I’ve seen here (about AMP, etc), and a similar request people have been making for Jekyll.
[[Edited for Length]]
Both would be great, but my vote is for custom output types, with the caveat that they be referred to as something other than “type.”
Lets try to keep this discussion about what and not so much how.
I wouldn’t have the first idea how to implement this in Hugo. Option B, IMHO, FWIW.
Before we set all of this in stone, we should spend some time labeling backlogged issues. We currently have 36 labeled Bugs. I’m sure there are more that just haven’t been reviewed and labeled. (It seems like staticgen.com should deduct points for open bugs. Hehe) I’d love to see our number of bugs reduced.
One item we ought to deal in the 0.20 release:
Custom output types 
Me too. I added the “stale” label on 60+ issues yesterday. Issues not updated for the last 2 years. Jekyll has this bot GitHub - parkr/auto-reply: ➿ Handle GitHub webhooks and manage issues on your repositories. Used to run @jekyllbot, now at github.com/jekyll/jekyllbot that adds a message to old issues then closes them if nothing happens for some time:
See the comment here:
We should consider something similar. Issues from 2014 MAY possibly still be relevant and important, but then I would say that someone should create a new issue with up-to-date text for a newer Hugo version.
But please take this discussion in another thread. This is about the “big lines of Hugo 0.20”, and while bug fixes are important, and we do a lot of it, I’m not doing any “bug fix only” release. This discussion does not set anything in stone, and if someone could do some work with labels/bugs/priority etc. in parallel to this, that would be great.
Some of these have already been marked stale; I can delete if not a “big-line item.”
{{.TableOfContents}} is a fantastic feature, but you often need both CSS and JS hacks to make it workable. I believe this is a BlackFriday issue. I would love if v20 Hugo had it’s own, more customizable solution.
GH issues (to keep post shorter): one, two, three, four, five
+1, vital. It’s not just for AMPs, for us using Lunr.js we could also easily generate the search index directly (without custom build commands) as a json-file as Bep mentioned in an example a while back
Custom output types is something that would benefit everyone running sites of nontrivial size, and is a great “enabling” technology with lots of potential synergies, much like data files. A hearty !
I vote for multi level section support.
I’d like to see multi level sections support. Especially an easier configuration of nested menus would be nice.
I second, nay third, the motion for multi-level, for practical reasons. Seems like it may help guide implementation for custom types, saving work if not performed in that sequence (assuming both are implemented).
I haven’t counted, but it is just about even, and I guess my vote pulls it in the favour of “Custom Output Types”. I have created a start with some exploratory code here:
Further comments/suggestions should go into that PR.
I hope that “custom output” includes support for the Pandoс.
That’s an interesting idea as an external helper, but not for this feature since this is about Hugo(lang) code and not Haskell. I love Pandoc though 
Could these two be considered for 0.20?
Only if someone (other than me) wants to work on them. Any takers?