With the current implementation of FSE, there is a big disconnect and schism between "classic" and FSE themes. However, with a few changes, we can be more versatile and fluid, ultimately making the transition to FSE easier for both themers & end-users.
For starters, we should have no such concept as an "FSE theme". An FSE theme is nothing but a theme that only uses FSE templates.

• Themes should not have to opt-in to FSE.
• FSE should not be on a per-theme basis, but on a per-template basis. A “classic” theme can just have the single-post template as a block-template, while everything else is on a PHP structure.
• Users should be able to create an FSE template on any theme, without affecting the overall theme structure. So if a user creates a template called page-67, then the theme should work like before - with the exception of page 67 where the user-created template will take precedence.

The templating system can work like this:

• If there is a user-edited FSE template, use that.
• If there is no user-edited FSE template, but there is a block template, use the block template (currently the block-templates/*.html files)
• If there is no user-edited FSE template and no block-template file in the theme, fallback to the .php file.

With the above priorities and checks in place, we could accomplish hybrid themes.
It will not be classic OR FSE; it will be a mix that can support both PHP templates & block templates, both for page templates and template-parts. The result will be an easier migration path and more granular control.

Themers could start migrating their template-parts one at a time, and they can be picked up by the get_template_part() function in the beginning. Then they can move on to migrating the structure of full templates one at a time, without the need to do everything in a single time-consuming and over-complex migration.
The current implementation of requiring an explicit "FSE theme" works fine while in the experimental/development phase, so it's an intermediate step, a stage in the path towards FSE in Core. But it should not be the end-goal.
In order to get where we want to go with the templating system, we need to make a few changes and take a lot some things into account.

Template priorities

This one seems like a non-brainer. User-edited (or user-created) templates should be loaded first with a fallback to theme-provided block templates and ultimately a fallback to a php template if one exists.

Big-picture questions:

• What happens when the user has saved a template and then we switch themes?
• The site editor should not always be available in classic themes, but we need to find a way to make it available… Maybe a switch in the post-editor itself, making it possible to switch between editors and create a template for the post/page we were previously editing?
• How is the user going to create their 1st template in a “classic” theme?
• The “site-editor” admin menu should only show by default if the theme has a block-templates folder or if there are user-created block-templates.
• We should allow loading a PHP template-part in the template-part block. Needs some UI to make it clear that these are not editable but are use-as-is, or replace with custom

In the template overview, we could list all templates, both classic templates, FSE templates defined in the theme and User defined templates. When someone clicks a classic template, this opens the customizer. It's a much nicer gateway to the customizer anyway. If the classic templates are listed as well, we could create an option to create a custom template for them.

Related: #24313

Proof of concept PR: #29298