I think there is benefit to not cluttering this list up too much, versus an attempt to be comprehensive. I'm not sure separating contour and contourf is worth the extra entry(s)?

I like it seperate since I think a goal of this is making explicit implicit assumptions about data structure, in this case that it's unstructured coordinates. But kinda think this should go under the imshow/array section.

tricontour/f already had its own entry. The question here is whether we need separate entries for each of contour and contourf and tricontour and tricontourf.

Reading through the docs, I'm very confused about when to use the regular version vs. the f one, & that's not explained when collapsed into one example either. (I never remember that f stands for filled). I think separating the two here makes that clear, which I think is a good idea.

Again, I don't think the goal here is to be comprehensive, but rather to give folks enough knowledge to know what to search for. In this case both ax.contour and ax.contourf link to the respective methods. The first sentence of either method is:
contour and contourf draw contour lines and filled contours, respectively.

When I click through, the first sentence I see on both methods is

Draw contour lines on an unstructured triangular grid.

https://matplotlib.org/devdocs/api/_as_gen/matplotlib.pyplot.tricontourf.html?highlight=tricontourf#matplotlib.pyplot.tricontourf

which I think is because of #17742?

And for me it's not about comprehensive, it's that contour and contourf have different use cases* and collapsing them like this makes that unclear.

Eta: what I mean by use cases isn't actually use cases, it's that the contour is visually encoding a line, contourf is visually encoding an area

Sure, if folks think they are distinct enough, they should get separate entries. I don't think they are, but that is just my opinion.

I think they are distinct enough visually.

IMHO the main use case of "Plot types" is to look at the plots and decide which visual representation you want. And for that lines and filled areas are quite different. That they encode the same type of information is secondary. It's somewhat analogous to stem() encoding the same as bar() (or even plot() with marker only, but certainly you won't trade it easily for the others and would want to see that all of them exist.

Note: I had to rename: examples/frontpage/contour.py → examples/frontpage/contour_frontpage.py

Apparently, Sphinx-gallery doesn't like the same name in different galleries:

WARNING: Duplicate example file name(s) found. Having duplicate file names will break some links. List of files: ['../plot_types/arrays/contour.py']

While the above renaming breaks someone external linking the front page coutour example, I anticipate that that'd be avery rare case and I willing to take that so that we have more consistent names in the plot_types.

Needs a rebate needs a rebase cause of #21123