Thinking about this... it's a tricky problem, excuse the rough notes! 😅

This is how starter content works currently:

• If the fresh_site option is set then we import a bunch of fake posts, widgets, menus into the current Customizer changeset on after_theme_setup.
• This appears in the Customizer because the Customizer will use the current URL to determine which templates to render. For example if the URL being customised is / then the page with slug home will appear.
• Modifying the database in any way (e.g. publishing a post) will unset the fresh_site option.

But full site editing is different:

• There are no changesets. What you see in the Site Editor is the published content that comes back via the REST API.
  • We do, however, have local changes made to WordPress entities that exist in memory (@wordpress/data).
• Users pick a template or template part to edit. It's not automatic. You can, for example, edit the index or page-home template but the Site Editor won't choose one for you based on the URL being /.
• There's no real need for fake widgets and menus, just fake posts and perhaps template parts (e.g. to fake a navigation).

Perhaps we can set up a system where the theme can define a set of fake entities that the block editor loads into @wordpress/data after initialisation. I'm not sure how to have the Site Editor display the home page by default, though.

I'm also not sure if it will be confusing that starter content looks exactly like real content except for that it disappears when you make a change and doesn't appear in the site's frontend. I suppose we already have this problem. Still, this is a good opportunity to figure out if there is a better way to solve the problem that starter content solves.