Note: I'll only mention "templates" for brevity, but this applies to both templates and template parts.

Templates used in Full Site Editing can have different origins (or, as I've called them in #26394, "sources").

• Themes can provide them as HTML files in the block-templates folder; likely plugins will be able to provide their owns as well. Whenever the template loader runs (for example, when opening the Site Editor), these files are converted into wp_template posts.
• Users can create their own templates in the Site Editor, or from Appearance -> Templates.
• Users can update templates provided by themes and plugins, practically making them their own.

The original WP template hierarchy relies on file names to determine which template is used for any given content.

FSE templates aim to recreate the same experience (if anything, for backward compatibility reasons), relying on slugs instead.

This means that it's extremely easy to end up with multiple wp_template posts with the same slug, which can each be used for their corresponding content.

For example, if I activate an FSE-ready theme containing the index template, and then I activate another FSE-ready theme with its own index template, my site will contain 2 different index templates, without a clear way to determine which one will be used.

In #26394 I've added a theme post meta to wp_template, which stores the theme that originally provided that template (wp_template_part already has the same post meta).
This is not enough to address potential conflicts, but it's at least a start.

Automatically Choosing the Appropriate Template

At first we should probably figure out a way to automatize the template choice, on a per-slug basis.

• If there is only 1 template with the slug matching the current content, and it was either provided by the current theme, or it's customized by the user, the site will use that.

• If the only relevant template was provided by an inactive theme, should the site still use it, even if it might not match the current theme design?

• Given the choice, templates customized by the user will have the priority over "siblings".

• What about plugin-provided templates? Should they be prioritized over theme-provided ones?

• What happens if, for example, a site has a user-customized index, and afterwards the user activates a theme which includes its own index? Should we also favour the creation (in this case "conversion from file") date of the wp_template post?

Manually Choosing the Appropriate Template

We don't really have a way to do this right now, but it might be useful, especially as an escape hatch when the automatic choice is not picking the expected template (note: "expected" != "correct").

We could approach this from the template side, or from the content side.

Setting Default Templates

Similarly to how we handle the page order, we could add a new custom field to wp_template.

It could be a number field, working like the page order but on a per-slug basis (e.g. index templates will have their own order, separate from singular templates order), but it will probably become messy when new templates are created.

Another way could be to simply have a "Make template default for its corresponding content" checkbox.
Checking it on a template would automatically uncheck it on other templates with the same slug that had been previously set as default.
Should creating new templates (either manually or via file conversion) affect this value?

Assigning Templates to Content

Similarly to how we handle custom templates for pages, we could create an interface that visually recreates the template hierarchy with the available templates, letting the user pick their preferred template when there's a possible choice.

Such interface could be also handy to let users "toggle" templates for a content.
E.g. the site has a front-page template, but the user would rather use index for the Front Page. Currently the only way would be to remove front-page from the site.
A toggle could switch the template between draft and published (for example), "opening and closing" the hierarchy fallback flows.

I'm sure there are other possibilities, but I think these might be the most likely to happen.

If some of these proposal seems too far out, it's because they are mostly supposed to be a way to kickstart a discussion about duplicate templates.