Here is another idea that provides more detail on another scenario.

community.sdl.com/.../differentiating-icons-for-metadata-schemas-and-embeddable-schemas

But instead of just adding icons, the same name (type) column would provide the name of the schema type in the same way components show the component type (schema name).

In most of my implementations I had the team limit the number of Page Templates (PTs), regardless of rendering approach. So you might see a PT for the majority of pages with some special options for the homepage or navigation. The variation of page types is handled by what content is placed on the page.

I'd still recommend a small set of PTs with a few matching Page (Region) Schemas. In this case showing either Page Template or Page Schema would make sense in the type column. If Page Schema is somehow slower to display, go for PT.

The initial introduction of Regions may encourage a bigger variety of region arrangements and thus more PTs. Well least until users can create and add their own Regions to pages.

What would ECL items show? And does Type matter more or less in the Favorites list?

Ideally "Type" would show the original "Page Type" an XPM page is based on, but that's probably a bit more involved than this idea. :-)

"Would it be equally valuable to see the Page Schema/Type in the list view?"

"Alternatively, you can argue that Page Templates acts as Page Types; would it be useful to see the Page Template? Would that be more useful than Page Schema?"

Based on what I understand about page schemas, I think it is appropriate and consistent that the column shows which schema the current row uses, be that component, page, etc. I am not sure if folder and structure group metadata schemas would also be included in that view, as it may cause confusion since pages can also have a metadata schema (which may be inherited from the new "page schema").

Page template may be useful for older implementations, but since switching to using DXA, the number of page templates we use has reduced and they are all identical other than the names.

This is currently one of the most popular ideas (by number of votes) and we are considering taking this in for the SDL Tridion Sites 9.1 release.  Please provide feedback on the questions (in the orange box) to give us a better idea of the scope of this feature.

Schema names in the list view are helpful for us because many times our folders contain components which are all related and component linked to each other, often with similar names and each belonging to a different schema. Currently we would need to name each component based on it's schema.

Example: (Parent folder = something)

something-container

something-hello-text

something-goodbye-text

something-config

something-home-link

something-detail-link

something-hello-image

something-goodbye-image

Now imagine that I didn't add the -container, -text, -config, -link, and -image to the component names, and that's what we're looking at now. We could add the component schema name to the component names manually in this way but naming components based on their schema seems like a unnecessary extra step when that information already exists, and doesn't allow for the same filtering and sorting that a new column allows for.

We will be programmatically importing tens of thousands of components from legacy systems into our SDL Web instance and although we could add the schema name to the component name on import, that seems like the wrong thing to do. Content producers creating content manually will have to follow the same process if they want to keep things consistent.

The legacy systems we're importing from display the content types (schema) in their list views and our users expect it from SDL Web. From our experience across multiple CMS's, it's been a standard feature.